Re: A failure in 031_recovery_conflict.pl on Debian/s390x - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: A failure in 031_recovery_conflict.pl on Debian/s390x
Date
Msg-id CA+hUKGK_bSq+pU=UKvDrSM-E6eAMbc_8CNPde48qXys7Boyb_A@mail.gmail.com
Whole thread Raw
In response to Re: A failure in 031_recovery_conflict.pl on Debian/s390x  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.

Attachment

pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Synchronizing slots from primary to standby
Next
From: Michael Paquier
Date:
Subject: Re: pg_basebackup: Always return valid temporary slot names