public inbox for [email protected]
help / color / mirror / Atom feedpgsql: Skip pg_database.dathasloginevt cleanup on standby
3+ messages / 1 participants
[nested] [flat]
* pgsql: Skip pg_database.dathasloginevt cleanup on standby
@ 2026-05-26 23:46 Alexander Korotkov <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Korotkov @ 2026-05-26 23:46 UTC (permalink / raw)
To: [email protected]
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 <[email protected]>
Reported-by: Egor Chindyaskin <[email protected]>
Reviewed-by: Fujii Masao <[email protected]>
Reviewed-by: Alexander Korotkov <[email protected]>
Discussion: https://postgr.es/m/19488-d7ccfca2bf6b74b0%40postgresql.org
Backpatch-through: 17
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/bec61f59354e652598b4c8b52b4c022ebb616230
Modified Files
--------------
src/backend/commands/event_trigger.c | 10 +-
src/test/recovery/meson.build | 1 +
.../recovery/t/053_standby_login_event_trigger.pl | 125 +++++++++++++++++++++
3 files changed, 135 insertions(+), 1 deletion(-)
^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Skip pg_database.dathasloginevt cleanup on standby
@ 2026-05-26 23:46 Alexander Korotkov <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Korotkov @ 2026-05-26 23:46 UTC (permalink / raw)
To: [email protected]
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 <[email protected]>
Reported-by: Egor Chindyaskin <[email protected]>
Reviewed-by: Fujii Masao <[email protected]>
Reviewed-by: Alexander Korotkov <[email protected]>
Discussion: https://postgr.es/m/19488-d7ccfca2bf6b74b0%40postgresql.org
Backpatch-through: 17
Branch
------
REL_18_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/97b5c5aaad5dba2144215293d4b8438df693c13b
Modified Files
--------------
src/backend/commands/event_trigger.c | 10 +-
src/test/recovery/meson.build | 3 +-
.../recovery/t/053_standby_login_event_trigger.pl | 125 +++++++++++++++++++++
3 files changed, 136 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Skip pg_database.dathasloginevt cleanup on standby
@ 2026-05-26 23:46 Alexander Korotkov <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Korotkov @ 2026-05-26 23:46 UTC (permalink / raw)
To: [email protected]
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 <[email protected]>
Reported-by: Egor Chindyaskin <[email protected]>
Reviewed-by: Fujii Masao <[email protected]>
Reviewed-by: Alexander Korotkov <[email protected]>
Discussion: https://postgr.es/m/19488-d7ccfca2bf6b74b0%40postgresql.org
Backpatch-through: 17
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/4a375527a19545dff0321349c42659e5f097d94b
Modified Files
--------------
src/backend/commands/event_trigger.c | 10 +-
src/test/recovery/meson.build | 3 +-
.../recovery/t/053_standby_login_event_trigger.pl | 125 +++++++++++++++++++++
3 files changed, 136 insertions(+), 2 deletions(-)
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-05-26 23:46 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-05-26 23:46 pgsql: Skip pg_database.dathasloginevt cleanup on standby Alexander Korotkov <[email protected]>
2026-05-26 23:46 pgsql: Skip pg_database.dathasloginevt cleanup on standby Alexander Korotkov <[email protected]>
2026-05-26 23:46 pgsql: Skip pg_database.dathasloginevt cleanup on standby Alexander Korotkov <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox