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

commit    bec61f59354e652598b4c8b52b4c022ebb616230
Author:   Alexander Korotkov <akorotkov@postgresql.org>
Date:     Tue May 26 23:26:50 2026 +0000

    Skip pg_database.dathasloginevt cleanup on standby
    
    EventTriggerOnLogin() tries to clear pg_database.dathasloginevt when
    the database no longer has any login event triggers but the flag is
    still set.  To make that safe against concurrent flag setters, it
    takes a conditional AccessExclusiveLock on the database object.
    
    On a hot standby, that lock acquisition fails outright with
    
      FATAL:  cannot acquire lock mode AccessExclusiveLock on database
              objects while recovery is in progress
    
    because LockAcquireExtended() refuses locks stronger than
    RowExclusiveLock on database objects during recovery.  The standby
    already replays the flag's value from the primary, so the dangling
    flag is the result of replaying a state in which the primary had
    already dropped its login event triggers but not yet run a login
    event trigger pass to clear the flag.  Any session connecting to the
    standby in that window therefore fails to connect.
    
    Skip the cleanup on a standby.  The flag will be cleared via WAL
    replay once the primary clears it on its side.
    
    Add a recovery TAP test that reproduces the original report: create
    and drop a login event trigger on the primary in one session, wait
    for the standby to replay, then verify that a fresh connection to
    the standby succeeds.
    
    Backpatch to v17, where the login event triggers were introduced.
    
    Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
    Reported-by: Egor Chindyaskin <kyzevan23@mail.ru>
    Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
    Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
    Discussion: https://postgr.es/m/19488-d7ccfca2bf6b74b0%40postgresql.org
    Backpatch-through: 17

[parent: 490259d07290]