From bee33974ee726785a674fafd1c58f8d0cd9c6667 Mon Sep 17 00:00:00 2001 From: Alexander Korotkov Date: Tue, 8 Sep 2026 13:30:55 +0300 Subject: [PATCH] Revert "Mark modified the FSM buffer as dirty during recovery" This reverts commit c06d1a4ba6b26eef27b04074683cccade6c277ee. The commit assumed that if the FSM code tolerates torn pages, everything else does so. Readers that do not tolerate that include RelationCopyStorage(), used by ALTER TABLE ... SET TABLESPACE for every fork, the read stream in RelationCopyStorageUsingBuffer() used by CREATE DATABASE ... STRATEGY = wal_log, and, most awkwardly, the checksum verification in base backups and pg_checksums. Reported-by: Noah Misch Discussion: https://postgr.es/m/20260901211837.f6.noahmisch%40microsoft.com Backpatch-through: 14 Reviewed-by: Andrey Borodin --- src/backend/storage/freespace/freespace.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/src/backend/storage/freespace/freespace.c b/src/backend/storage/freespace/freespace.c index 68d77f1a365..b1262ac3b69 100644 --- a/src/backend/storage/freespace/freespace.c +++ b/src/backend/storage/freespace/freespace.c @@ -231,18 +231,8 @@ XLogRecordPageWithFreeSpace(RelFileLocator rlocator, BlockNumber heapBlk, if (PageIsNew(page)) PageInit(page, BLCKSZ, 0); - /* - * Changes to FSM are usually marked as changed using MarkBufferDirtyHint; - * however, during recovery, it does nothing if checksums are enabled. It - * is assumed that the page should not be dirtied during recovery while - * modifying hints to prevent torn pages, since no new WAL data can be - * generated at this point to store FPI. This is not relevant to the FSM - * case, as its blocks are zeroed when a checksum mismatch occurs. So, we - * need to use regular MarkBufferDirty here to mark the FSM block as - * modified during recovery, otherwise changes to the FSM may be lost. - */ if (fsm_set_avail(page, slot, new_cat)) - MarkBufferDirty(buf); + MarkBufferDirtyHint(buf, false); UnlockReleaseBuffer(buf); }