Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>

To: Christoph Berg <myon@debian.org>

Cc: Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2023-08-12T03:50:24Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix instability in 031_recovery_conflict.pl.
- 0174c2d213f6 17.0 landed
Fix recovery conflict SIGUSR1 handling.
- 0da096d78e1e 17.0 landed
Disable 031_recovery_conflict.pl in 15 and 16.
- e13de4913913 15.5 landed
- 8d1cf9674a25 16.0 landed

Thanks.  I realised that it's easy enough to test that theory about
cleanup locks by hacking ConditionalLockBufferForCleanup() to return
false randomly.  Then the test occasionally fails as described.  Seems
like we'll need to fix that test, but it's not evidence of a server
bug, and my signal handler refactoring patch is in the clear.  Thanks
for testing it!