Commit
b10714080 moved the GinPageSetDeleteXid() call to a spot where
the "page" variable was pointing to the wrong page, causing the XID
to be inserted on a page that's not being deleted, thus allowing later
GinPageIsRecyclable tests to recycle the deleted page too soon.
It might be a good idea to stop using the single "page" variable for
multiple purposes in this function. But for the moment I just moved
the GinPageSetDeleteXid() call down beside the GinPageSetDeleted()
call, which seems like a more logical place for it anyway.
Back-patch to v11, as the faulty patch was. (Fortunately, the bug
hasn't made it into any release yet.)
Discussion: https://postgr.es/m/21620.
1581098806@sss.pgh.pa.us
index 0c8f4b1337266e53883bc22dc581bf837643bb2c..10d814d4aae7d9b8683a4cb640ff40b81018f9ee 100644 (file)
@@ -165,9 +165,6 @@ ginDeletePage(GinVacuumState *gvs, BlockNumber deleteBlkno, BlockNumber leftBlkn
page = BufferGetPage(lBuffer);
GinPageGetOpaque(page)->rightlink = rightlink;
- /* For deleted page remember last xid which could knew its address */
- GinPageSetDeleteXid(page, ReadNewTransactionId());
-
/* Delete downlink from parent */
parentPage = BufferGetPage(pBuffer);
#ifdef USE_ASSERT_CHECKING
@@ -186,7 +183,13 @@ ginDeletePage(GinVacuumState *gvs, BlockNumber deleteBlkno, BlockNumber leftBlkn
* we shouldn't change rightlink field to save workability of running
* search scan
*/
+
+ /*
+ * Mark page as deleted, and remember last xid which could know its
+ * address.
+ */
GinPageSetDeleted(page);
+ GinPageSetDeleteXid(page, ReadNewTransactionId());
MarkBufferDirty(pBuffer);
MarkBufferDirty(lBuffer);