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

Commit1c15aac

Browse files
committed
Add comment & docs about no vacuum truncation with sto.
Omission noted by Andres Freund.
1 parentb11e9bb commit1c15aac

File tree

2 files changed

+18
-0
lines changed

2 files changed

+18
-0
lines changed

‎doc/src/sgml/config.sgml

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2091,6 +2091,15 @@ include_dir 'conf.d'
20912091
transaction ID wraparound may occur in much shorter time frames.
20922092
</para>
20932093

2094+
<para>
2095+
When this feature is enabled, freed space at the end of a relation
2096+
cannot be released to the operating system, since that could remove
2097+
information needed to detect the <literal>snapshot too old</>
2098+
condition. All space allocated to a relation remains associated with
2099+
that relation for reuse only within that relation unless explicitly
2100+
freed (for example, with <command>VACUUM FULL</>).
2101+
</para>
2102+
20942103
<para>
20952104
This setting does not attempt to guarantee that an error will be
20962105
generated under any particular circumstances. In fact, if the

‎src/backend/commands/vacuumlazy.c

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1663,6 +1663,15 @@ lazy_cleanup_index(Relation indrel,
16631663
* Don't even think about it unless we have a shot at releasing a goodly
16641664
* number of pages. Otherwise, the time taken isn't worth it.
16651665
*
1666+
* Also don't attempt it if we are doing early pruning/vacuuming, because a
1667+
* scan which cannot find a truncated heap page cannot determine that the
1668+
* snapshot is too old to read that page. We might be able to get away with
1669+
* truncating all except one of the pages, setting its LSN to (at least) the
1670+
* maximum of the truncated range if we also treated an index leaf tuple
1671+
* pointing to a missing heap page as something to trigger the "snapshot too
1672+
* old" error, but that seems fragile and seems like it deserves its own patch
1673+
* if we consider it.
1674+
*
16661675
* This is split out so that we can test whether truncation is going to be
16671676
* called for before we actually do it. If you change the logic here, be
16681677
* careful to depend only on fields that lazy_scan_heap updates on-the-fly.

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp