Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit fae54e4

Browse files
committed
Update visibilitymap.c header comments.
Recent work on index-only scans left this somewhat out of date.
1 parent 7609239 commit fae54e4

File tree

1 file changed

+17
-16
lines changed

1 file changed

+17
-16
lines changed

src/backend/access/heap/visibilitymap.c

+17-16
Original file line numberDiff line numberDiff line change
@@ -27,22 +27,28 @@
2727
* the sense that we make sure that whenever a bit is set, we know the
2828
* condition is true, but if a bit is not set, it might or might not be true.
2929
*
30-
* There's no explicit WAL logging in the functions in this file. The callers
30+
* Clearing a visibility map bit is not separately WAL-logged. The callers
3131
* must make sure that whenever a bit is cleared, the bit is cleared on WAL
32-
* replay of the updating operation as well. Setting bits during recovery
33-
* isn't necessary for correctness.
32+
* replay of the updating operation as well.
3433
*
35-
* Currently, the visibility map is only used as a hint, to speed up VACUUM.
36-
* A corrupted visibility map won't cause data corruption, although it can
37-
* make VACUUM skip pages that need vacuuming, until the next anti-wraparound
38-
* vacuum. The visibility map is not used for anti-wraparound vacuums, because
34+
* When we *set* a visibility map during VACUUM, we must write WAL. This may
35+
* seem counterintuitive, since the bit is basically a hint: if it is clear,
36+
* it may still be the case that every tuple on the page is visible to all
37+
* transactions; we just don't know that for certain. The difficulty is that
38+
* there are two bits which are typically set together: the PD_ALL_VISIBLE bit
39+
* on the page itself, and the visibility map bit. If a crash occurs after the
40+
* visibility map page makes it to disk and before the updated heap page makes
41+
* it to disk, redo must set the bit on the heap page. Otherwise, the next
42+
* insert, update, or delete on the heap page will fail to realize that the
43+
* visibility map bit must be cleared, possibly causing index-only scans to
44+
* return wrong answers.
45+
*
46+
* VACUUM will normally skip pages for which the visibility map bit is set;
47+
* such pages can't contain any dead tuples and therefore don't need vacuuming.
48+
* The visibility map is not used for anti-wraparound vacuums, because
3949
* an anti-wraparound vacuum needs to freeze tuples and observe the latest xid
4050
* present in the table, even on pages that don't have any dead tuples.
4151
*
42-
* Although the visibility map is just a hint at the moment, the PD_ALL_VISIBLE
43-
* flag on heap pages *must* be correct, because it is used to skip visibility
44-
* checking.
45-
*
4652
* LOCKING
4753
*
4854
* In heapam.c, whenever a page is modified so that not all tuples on the
@@ -72,11 +78,6 @@
7278
* But when a bit is cleared, we don't have to do that because it's always
7379
* safe to clear a bit in the map from correctness point of view.
7480
*
75-
* TODO
76-
*
77-
* It would be nice to use the visibility map to skip visibility checks in
78-
* index scans.
79-
*
8081
*-------------------------------------------------------------------------
8182
*/
8283
#include "postgres.h"

0 commit comments

Comments
 (0)