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

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Christoph Berg <myon(at)debian(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: A failure in 031_recovery_conflict.pl on Debian/s390x
Date: 2023-08-12 03:50:24
Message-ID: CA+hUKGKYNHmL_DhmVRiidHv6YLAL8jViifwwn2ABY__Y3BCphg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-08-12 04:03:27 Re: Adding a LogicalRepWorker type field
Previous Message Jeff Davis 2023-08-12 02:35:22 CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }