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 ------ master Details ------- https://git.postgresql.org/pg/commitdiff/80cf51123601318a7d80a4eec7be568e22462a4c Modified Files -------------- .../recovery/t/053_standby_login_event_trigger.pl | 24 ++++++++-------------- 1 file changed, 9 insertions(+), 15 deletions(-)
