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

commit    b4c1b2be300e619aebc3a2c00198009af256bfee
Author:   Melanie Plageman <melanieplageman@gmail.com>
Date:     Thu Apr 16 16:10:47 2026 +0000

    Update FSM during prune/freeze replay even if freespace is zero
    
    add323da40a started updating the visibility map in the same WAL record
    as pruning and freezing. This included updating the freespace map during
    replay of a record setting the VM, which we've done since ab7dbd681.
    
    add323da40a, however, conditioned doing so on there being > 0 freespace
    on the page, which differed from the previous state for records updating
    the VM.
    
    The FSM is not WAL-logged and is instead updated heuristically on
    standbys. In rare cases, this heuristic could lead to pages with 0
    freespace having outdated entries in the FSM. If the standby is later
    promoted and vacuum skips these pages because they are marked
    all-visible/all-frozen, overly optimistic values would be propagated up
    the FSM tree, causing slowness when searching for freespace for new
    tuples.
    
    Fix it by always updating the FSM during replay when setting VM bits.
    
    Author: Melanie Plageman <melanieplageman@gmail.com>
    Reported-by: Alexey Makhmutov <a.makhmutov@postgrespro.ru>
    Discussion: https://postgr.es/m/ead2f110-c736-48f5-99e1-023dc9acbf0b%40postgrespro.ru

[parent: af1ed03739fb]