|
27 | 27 | * the sense that we make sure that whenever a bit is set, we know the
|
28 | 28 | * condition is true, but if a bit is not set, it might or might not be true.
|
29 | 29 | *
|
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 |
31 | 31 | * 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. |
34 | 33 | *
|
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 |
39 | 49 | * an anti-wraparound vacuum needs to freeze tuples and observe the latest xid
|
40 | 50 | * present in the table, even on pages that don't have any dead tuples.
|
41 | 51 | *
|
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 |
| - * |
46 | 52 | * LOCKING
|
47 | 53 | *
|
48 | 54 | * In heapam.c, whenever a page is modified so that not all tuples on the
|
|
72 | 78 | * But when a bit is cleared, we don't have to do that because it's always
|
73 | 79 | * safe to clear a bit in the map from correctness point of view.
|
74 | 80 | *
|
75 |
| - * TODO |
76 |
| - * |
77 |
| - * It would be nice to use the visibility map to skip visibility checks in |
78 |
| - * index scans. |
79 |
| - * |
80 | 81 | *-------------------------------------------------------------------------
|
81 | 82 | */
|
82 | 83 | #include "postgres.h"
|
|
0 commit comments