From e4cc408acd2d5ef56d717930b0873eedb4c9ba2e Mon Sep 17 00:00:00 2001 From: Fujii Masao Date: Sat, 17 Oct 2026 00:18:39 +0900 Subject: [PATCH] Avoid spurious failures in the login event trigger recovery test Buildfarm member skink reported failures in 053_standby_login_event_trigger.pl. The checks that dathasloginevt was cleared on the primary and that the cleared flag reached the standby both found the flag still set. The test assumed that the first login after dropping the trigger would clear the flag. However, EventTriggerOnLogin() acquires the database lock conditionally to avoid delaying connections for this cleanup. Concurrent connection startup, including that of an autovacuum worker, can hold a conflicting lock and cause the cleanup to be skipped. The standby correctly retained the flag because it had not been cleared on the primary. Fix this by using poll_query_until() to retry with fresh connections to the test database until the flag is cleared, giving the login cleanup repeated opportunities to acquire the lock. Backpatch to v17, like commit bec61f59354, which added this test. Reported-by: Alexander Lakhin Author: Ayush Tiwari Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/09561429-50c1-4d06-a262-300c7a845175@gmail.com Backpatch-through: 17 --- .../t/053_standby_login_event_trigger.pl | 24 +++++++------------ 1 file changed, 9 insertions(+), 15 deletions(-) diff --git a/src/test/recovery/t/053_standby_login_event_trigger.pl b/src/test/recovery/t/053_standby_login_event_trigger.pl index 81903379092..03d0fdc4b97 100644 --- a/src/test/recovery/t/053_standby_login_event_trigger.pl +++ b/src/test/recovery/t/053_standby_login_event_trigger.pl @@ -97,21 +97,15 @@ unlike( qr/cannot acquire lock mode AccessExclusiveLock/, 'no AccessExclusiveLock FATAL on standby login'); -# Finally exercise the primary-side cleanup that the standby is meant -# to defer to. Opening a fresh session against regress_login_evt on -# the primary enters EventTriggerOnLogin()'s cleanup branch with the -# trigger list empty; AccessExclusiveLock is allowed outside recovery, -# so the flag is cleared in place. The in-place update emits a -# XLOG_HEAP_INPLACE record but does not assign an xid or write a -# commit record, so the WAL is not auto-flushed -- force a flush via -# pg_switch_wal() so the record reaches the standby. -$primary->safe_psql('regress_login_evt', 'SELECT 1'); -is( $primary->safe_psql( - 'postgres', - "SELECT dathasloginevt FROM pg_database WHERE datname = 'regress_login_evt'" - ), - 'f', - 'primary clears dathasloginevt on next login after DROP'); +# Cleanup's conditional database lock can fail, so retry fresh logins. +# The in-place update emits a XLOG_HEAP_INPLACE record but does not assign +# an xid or write a commit record, so the WAL is not auto-flushed -- force +# a flush via pg_switch_wal() so the record reaches the standby. +ok( $primary->poll_query_until( + 'regress_login_evt', + "SELECT dathasloginevt FROM pg_database WHERE datname = 'regress_login_evt'", + 'f'), + 'primary eventually clears dathasloginevt after DROP'); $primary->safe_psql('postgres', 'SELECT pg_switch_wal()'); $primary->wait_for_replay_catchup($standby);