pgsql: Avoid spurious failures in the login event trigger recovery test

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 <exclusion(at)gmail(dot)com>
Author: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
Reviewed-by: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Discussion: https://postgr.es/m/09561429-50c1-4d06-a262-300c7a845175@gmail.com
Backpatch-through: 17

Branch
------
REL_19_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/c705304a0f43d314239ffe62fe0f3a64443c19b0

Modified Files
--------------
.../recovery/t/053_standby_login_event_trigger.pl | 24 ++++++++--------------
1 file changed, 9 insertions(+), 15 deletions(-)