• Tom Lane's avatar
    Don't call palloc() while holding a spinlock, either. · f88bd313
    Tom Lane authored
    Fix some more violations of the "only straight-line code inside a
    spinlock" rule.  These are hazardous not only because they risk
    holding the lock for an excessively long time, but because it's
    possible for palloc to throw elog(ERROR), leaving a stuck spinlock
    behind.
    
    copy_replication_slot() had two separate places that did pallocs
    while holding a spinlock.  We can make the code simpler and safer
    by copying the whole ReplicationSlot struct into a local variable
    while holding the spinlock, and then referencing that copy.
    (While that's arguably more cycles than we really need to spend
    holding the lock, the struct isn't all that big, and this way seems
    far more maintainable than copying fields piecemeal.  Anyway this
    is surely much cheaper than a palloc.)  That bug goes back to v12.
    
    InvalidateObsoleteReplicationSlots() not only did a palloc while
    holding a spinlock, but for extra sloppiness then leaked the memory
    --- probably for the lifetime of the checkpointer process, though
    I didn't try to verify that.  Fortunately that silliness is new
    in HEAD.
    
    pg_get_replication_slots() had a cosmetic violation of the rule,
    in that it only assumed it's safe to call namecpy() while holding
    a spinlock.  Still, that's a hazard waiting to bite somebody, and
    there were some other cosmetic coding-rule violations in the same
    function, so clean it up.  I back-patched this as far as v10; the
    code exists before that but it looks different, and this didn't
    seem important enough to adapt the patch further back.
    
    Discussion: https://postgr.es/m/20200602.161518.1399689010416646074.horikyota.ntt@gmail.com
    f88bd313
slot.c 46 KB