postgres-github.git / summary / log / commit / refs

commit    c06d1a4ba6b26eef27b04074683cccade6c277ee
Author:   Alexander Korotkov <akorotkov@postgresql.org>
Date:     Sun May 03 17:23:50 2026 +0000

    Mark modified the FSM buffer as dirty during recovery
    
    The XLogRecordPageWithFreeSpace function updates the freespace map (FSM) data
    while replaying data-level WAL records during the recovery. If the FSM block
    is updated, it needs to be marked as modified. Currently, this is done with
    the MarkBufferDirtyHint call (as in all other cases for modifying FSM data).
    However, in the recovery context, this function will actually do nothing if
    checksums are enabled. It's assumed that the page should not be dirtied
    during recovery while modifying hints to protect against torn pages, since no
    new WAL data can be generated at this point to store FPI.
    
    Such logic does not seem fully aligned with the FSM case, as its blocks could
    be simply zeroed if a checksum mismatch is detected. Currently, changes to an
    FSM block could be lost if each change to that block occurs infrequently
    enough to allow it to be evicted from the cache. To persist the change, the
    modification needs to be performed while the FSM block is still kept in
    buffers and marked as dirty after receiving its FPI. If the block has already
    been cleaned, the change won't be persisted, so stored FSM blocks may remain
    in an obsolete state.
    
    If a large number of discrepancies between the data in leaf FSM blocks and the
    actual data blocks accumulate on the replica server, this could cause
    significant delays in insert operations after switchover. Such an insert
    operation may need to visit many data blocks marked as having sufficient
    space in the FSM, only to discover that the information is incorrect and the
    FSM records need to be corrected. In a heavily trafficked insert-only table
    with many concurrent clients performing inserts, this has been observed to
    cause several-second stalls, causing visible application malfunction. The
    desire to avoid such cases was the reason behind the commit ab7dbd681, which
    introduced an update of FSM data during the heap_xlog_visible invocation.
    However, an update to the FSM data on the standby side could be lost due to a
    missing 'dirty' flag, so there is still a possibility that a large number of
    FSM records will contain incorrect data. Note that having a zeroed FSM page
    in such a case (due to a checksum mismatch) is preferable, as a zero value
    will be interpreted as an indication of full data blocks, and the inserter
    will be routed to the next FSM block or to the end of the table.
    
    Given that FSM is ready to handle torn page writes and
    XLogRecordPageWithFreeSpace is called only during the recovery, there seems
    to be no reason to use MarkBufferDirtyHint here instead of a regular
    MarkBufferDirty call.
    
    Discussion: https://postgr.es/m/596c4f1c-f966-4512-b9c9-dd8fbcaf0928%40postgrespro.ru
    Author: Alexey Makhmutov <a.makhmutov@postgrespro.ru>
    Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
    Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>
    Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>

[parent: 21d290161b11]