Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit60f1f09

Browse files
Don't truncate heap when VACUUM's failsafe is in effect.
It seems like a good idea to bypass heap truncation when the wraparoundfailsafe mechanism (which was added in commit1e55e7d) is in effect.Deliberately don't bypass heap truncation in the INDEX_CLEANUP=off case,even though it is similar to the failsafe case. There is already aseparate reloption (and related VACUUM parameter) for that.Reported-By: Masahiko Sawada <sawada.mshk@gmail.com>Discussion:https://postgr.es/m/CAD21AoDWRh6oTN5T8wa+cpZUVpHXET8BJ8Da7WHVHpwkPP6KLg@mail.gmail.com
1 parent6c0373a commit60f1f09

File tree

1 file changed

+14
-11
lines changed

1 file changed

+14
-11
lines changed

‎src/backend/access/heap/vacuumlazy.c

Lines changed: 14 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -2139,9 +2139,8 @@ lazy_vacuum(LVRelState *vacrel, bool onecall)
21392139
* far in the past.
21402140
*
21412141
* From this point on the VACUUM operation will do no further index
2142-
* vacuuming or heap vacuuming. It will do any remaining pruning that
2143-
* may be required, plus other heap-related and relation-level
2144-
* maintenance tasks. But that's it.
2142+
* vacuuming or heap vacuuming. This VACUUM operation won't end up
2143+
* back here again.
21452144
*/
21462145
Assert(vacrel->do_failsafe);
21472146
}
@@ -2534,8 +2533,11 @@ lazy_check_needs_freeze(Buffer buf, bool *hastup, LVRelState *vacrel)
25342533
* relfrozenxid and/or relminmxid that is dangerously far in the past.
25352534
*
25362535
* Triggering the failsafe makes the ongoing VACUUM bypass any further index
2537-
* vacuuming and heap vacuuming. It also stops the ongoing VACUUM from
2538-
* applying any cost-based delay that may be in effect.
2536+
* vacuuming and heap vacuuming. Truncating the heap is also bypassed.
2537+
*
2538+
* Any remaining work (work that VACUUM cannot just bypass) is typically sped
2539+
* up when the failsafe triggers. VACUUM stops applying any cost-based delay
2540+
* that it started out with.
25392541
*
25402542
* Returns true when failsafe has been triggered.
25412543
*
@@ -3097,14 +3099,12 @@ lazy_cleanup_one_index(Relation indrel, IndexBulkDeleteResult *istat,
30973099
* Don't even think about it unless we have a shot at releasing a goodly
30983100
* number of pages. Otherwise, the time taken isn't worth it.
30993101
*
3102+
* Also don't attempt it if wraparound failsafe is in effect. It's hard to
3103+
* predict how long lazy_truncate_heap will take. Don't take any chances.
3104+
*
31003105
* Also don't attempt it if we are doing early pruning/vacuuming, because a
31013106
* scan which cannot find a truncated heap page cannot determine that the
3102-
* snapshot is too old to read that page. We might be able to get away with
3103-
* truncating all except one of the pages, setting its LSN to (at least) the
3104-
* maximum of the truncated range if we also treated an index leaf tuple
3105-
* pointing to a missing heap page as something to trigger the "snapshot too
3106-
* old" error, but that seems fragile and seems like it deserves its own patch
3107-
* if we consider it.
3107+
* snapshot is too old to read that page.
31083108
*
31093109
* This is split out so that we can test whether truncation is going to be
31103110
* called for before we actually do it. If you change the logic here, be
@@ -3118,6 +3118,9 @@ should_attempt_truncation(LVRelState *vacrel, VacuumParams *params)
31183118
if (params->truncate==VACOPT_TERNARY_DISABLED)
31193119
return false;
31203120

3121+
if (vacrel->do_failsafe)
3122+
return false;
3123+
31213124
possibly_freeable=vacrel->rel_pages-vacrel->nonempty_pages;
31223125
if (possibly_freeable>0&&
31233126
(possibly_freeable >=REL_TRUNCATE_MINIMUM||

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp