Re: BUG #19488: Standby connection fails after dropping on login event trigger enabled always

Hi,

On Wed, 20 May 2026 at 02:34, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference: 19488
> Logged by: Egor Chindyaskin
> Email address: kyzevan23(at)mail(dot)ru
> PostgreSQL version: 18.4
> Operating system: Ubuntu 26.04
> Description:
>
> Hello!
> In a master + physical standby setup, connection to the standby fails after
> creating a login event trigger on the master, enabling it as always, and
> then dropping it without reconnecting to the master.
> Also reproduces on master branch.
> Steps to reproduce:
>
> 1. Run the following SQL script on the master:
> CREATE OR REPLACE FUNCTION init_session()
> RETURNS event_trigger SECURITY DEFINER
> LANGUAGE plpgsql AS
> $$
> BEGIN
> RAISE NOTICE 'init_session';
> END;
> $$;
>
> CREATE EVENT TRIGGER init_session
> ON login
> EXECUTE FUNCTION init_session();
>
> ALTER EVENT TRIGGER init_session ENABLE ALWAYS;
>
> DROP EVENT TRIGGER init_session;
>
> 2. Try to connect to the standby:
> psql -p5433
>
> Result:
> psql: error: connection to server on socket "/tmp/.s.PGSQL.5433" failed:
> FATAL: cannot acquire lock mode AccessExclusiveLock on database objects
> while recovery is in progress
> HINT: Only RowExclusiveLock or less can be acquired on database objects
> during recovery.
>
> --
> With best regards,
> Egor Chindyaskin
>
> Postgres Professional: https://postgrespro.com

Thanks for the report and the precise repro.

The cause is in EventTriggerOnLogin(). When a session connects to a
database whose pg_database.dathasloginevt flag is set but no login
event triggers are actually present, the function tries to clear the
flag via:

ConditionalLockSharedObject(DatabaseRelationId, MyDatabaseId, 0,
AccessExclusiveLock);

On a hot standby, LockAcquireExtended() refuses any lock stronger than
RowExclusiveLock on LOCKTAG_OBJECT/LOCKTAG_RELATION while
RecoveryInProgress() is true, which surfaces as a FATAL on the new
connection. The standby ends up in this state precisely after your
steps because the primary set dathasloginevt = true while the trigger
was active, then dropped the trigger but (intentionally) left the
flag set on disk for the next normal connection to clean up. That
state replicates to the standby, and any subsequent connection on the
standby then enters the cleanup path and crashes.

A standby should not try to clear that flag itself(?) the only correct
update path on a standby is WAL replay from the primary.

Attached patch adds a RecoveryInProgress() check to skip the cleanup
branch on standbys. I think this needs to be backpatched too.

Regards,
Ayush