Update btree_xlog_delete() comments.
authorPeter Geoghegan <pg@bowt.ie>
Wed, 1 Jan 2020 19:32:07 +0000 (11:32 -0800)
committerPeter Geoghegan <pg@bowt.ie>
Wed, 1 Jan 2020 19:32:07 +0000 (11:32 -0800)
Commit fe97c61c updated LP_DEAD item deletion comments, but missed a
minor discrepancy on the REDO side.  Fix it now.

In passing, don't talk about the btree_xlog_vacuum() behavior within
btree_xlog_delete().  The reliance on XLOG_HEAP2_CLEANUP_INFO records
for recovery conflicts is already discussed within btvacuumpage() and
mentioned again in passing above btree_xlog_vacuum(), which seems
sufficient.

src/backend/access/nbtree/nbtree.c
src/backend/access/nbtree/nbtxlog.c

index f9e94c28c5b85703cccafa47c708c0b77fc3889d..8376a5e6b75946418d702ce6dec3a6fcf16af60a 100644 (file)
@@ -1208,9 +1208,10 @@ restart:
                                 * as long as the callback function only considers whether the
                                 * index tuple refers to pre-cutoff heap tuples that were
                                 * certainly already pruned away during VACUUM's initial heap
-                                * scan by the time we get here. (We can rely on conflicts
-                                * produced by heap pruning, rather than producing our own
-                                * now.)
+                                * scan by the time we get here. (XLOG_HEAP2_CLEANUP_INFO
+                                * records produce conflicts using a latestRemovedXid value
+                                * for the entire VACUUM, so there is no need to produce our
+                                * own conflict now.)
                                 *
                                 * Backends with snapshots acquired after a VACUUM starts but
                                 * before it finishes could have a RecentGlobalXmin with a
index 72d8432d3c202bfc63f0e28ba5e1614495f05abd..5eca4ab2727879065e26cd612ac15b3f2209ccc4 100644 (file)
@@ -428,14 +428,7 @@ btree_xlog_delete(XLogReaderState *record)
 
        /*
         * If we have any conflict processing to do, it must happen before we
-        * update the page.
-        *
-        * Btree delete records can conflict with standby queries.  You might
-        * think that vacuum records would conflict as well, but we've handled
-        * that already.  XLOG_HEAP2_CLEANUP_INFO records provide the highest xid
-        * cleaned by the vacuum of the heap and so we can resolve any conflicts
-        * just once when that arrives.  After that we know that no conflicts
-        * exist from individual btree vacuum records on that index.
+        * update the page
         */
        if (InHotStandby)
        {
@@ -463,10 +456,7 @@ btree_xlog_delete(XLogReaderState *record)
                        PageIndexMultiDelete(page, unused, xlrec->nitems);
                }
 
-               /*
-                * Mark the page as not containing any LP_DEAD items --- see comments
-                * in _bt_delitems_delete().
-                */
+               /* Mark the page as not containing any LP_DEAD items */
                opaque = (BTPageOpaque) PageGetSpecialPointer(page);
                opaque->btpo_flags &= ~BTP_HAS_GARBAGE;