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 <[email protected]> Author: Ayush Tiwari <[email protected]> Reviewed-by: Fujii Masao <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 17 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e4cc408acd2d5ef56d717930b0873eedb4c9ba2e Modified Files -------------- .../recovery/t/053_standby_login_event_trigger.pl | 24 ++++++++-------------- 1 file changed, 9 insertions(+), 15 deletions(-)
