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

commit    d79bf7612a07a6f053f4122a8bf88754217cd1c9
Author:   Masahiko Sawada <msawada@postgresql.org>
Date:     Wed May 27 23:25:56 2026 +0000

    Fix race between ProcSignalInit() and EmitProcSignalBarrier().
    
    Previously, ProcSignalInit() read the global barrier generation before
    publishing its PID into pss_pid. This created a race condition: a
    process could initialize its local generation with an older global
    value, while a concurrent EmitProcSignalBarrier() might skip that
    process because its pss_pid was still zero. This resulted in
    WaitForProcSignalBarrier() hanging indefinitely.
    
    Fix this by publishing pss_pid before reading psh_barrierGeneration
    with a memory barrier so that the store to pss_pid is ordered before
    the load. A concurrent EmitProcSignalBarrier() then either observes
    the published PID and signals this slot, or completes its generation
    increment before we load it.
    
    While this race has become more visible due to recent features using
    signal barriers in more places (such as online wal_level changes), the
    issue is theoretically present since signal barriers were introduced
    to release smgr caches (e.g., in DROP DATABASE). v14 has the
    procsiangl barrier infrastricutre but no in-tree caller that actually
    emits a barrier, so the case is unreachable there.
    
    This issue was also reported by buildfarm member flaviventris.
    
    Reported-by: Melanie Plageman <melanieplageman@gmail.com>
    Reviewed-by: Alexander Lakhin <exclusion@gmail.com>
    Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com>
    Discussion: https://postgr.es/m/CAEze2WgAJmWReDN7Chtba8Er2YBvKCoa0KVN25-1evnTrHsLyA@mail.gmail.com
    Backpatch-through: 15

[parent: 47ad2233fad4]