From d0518cb3e40503859e5dd17a0a75de9b8967fe4b 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 006edab9d77..40d67a96178 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); }