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: Andres Freund <andres@anarazel.de>

Cc: Christoph Berg <myon@debian.org>, Noah Misch <noah@leadboat.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2023-09-07T03:39:31Z

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

Attachments

0001-Update-recovery-conflict-stats-immediately.patch (text/x-patch) patch 0001

On Tue, Aug 8, 2023 at 11:08 AM Andres Freund <andres@anarazel.de> wrote:
> On 2023-08-07 12:57:40 +0200, Christoph Berg wrote:
> > v8 worked better. It succeeded a few times (at least 12, my screen
> > scrollback didn't catch more) before erroring like this:
>
> > [10:21:58.410](0.151s) ok 15 - startup deadlock: logfile contains terminated connection due to recovery conflict
> > [10:21:58.463](0.053s) not ok 16 - startup deadlock: stats show conflict on standby
> > [10:21:58.463](0.000s)
> > [10:21:58.463](0.000s) #   Failed test 'startup deadlock: stats show conflict on standby'
> > #   at t/031_recovery_conflict.pl line 332.
> > [10:21:58.463](0.000s) #          got: '0'
> > #     expected: '1'
>
> Hm, that could just be a "harmless" race. Does it still happen if you apply
> the attached patch in addition?

Do you intend that as the fix, or just proof of what's wrong?  It
looks pretty reasonable to me.  I will go ahead and commit this unless
you want to change something/do it yourself.  As far as I know so far,
this is the last thing preventing the mighty Debian/s390x build box
from passing consistently, which would be nice.