Horton

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

Christoph Berg <myon@debian.org>

View thread
From: Christoph Berg <myon@debian.org>
To: Thomas Munro <thomas.munro@gmail.com>
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-09T10:56:06Z
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 →

  1. Fix instability in 031_recovery_conflict.pl.

  2. Fix recovery conflict SIGUSR1 handling.

  3. Disable 031_recovery_conflict.pl in 15 and 16.

Attachments

Re: Thomas Munro
> On Wed, Aug 9, 2023 at 2:01 AM Christoph Berg <myon@debian.org> wrote:
> > Putting that patch on top of v8 made it pass 294 times before exiting
> > like this:
> >
> > [08:52:34.134](0.032s) ok 1 - buffer pin conflict: cursor with conflicting pin established
> > Waiting for replication conn standby's replay_lsn to pass 0/3430000 on primary
> > done
> > timed out waiting for match: (?^:User was holding shared buffer pin for too long) at t/031_recovery_conflict.pl line 318.
> 
> Can you reproduce that with logging like this added on top?

603 iterations later it hit again, but didn't log anything. (I believe
I did run "make" in the right directory.)

[22:20:24.714](3.145s) # issuing query via background psql:
#     BEGIN;
#     DECLARE test_recovery_conflict_cursor CURSOR FOR SELECT b FROM test_recovery_conflict_table1;
#     FETCH FORWARD FROM test_recovery_conflict_cursor;
[22:20:24.745](0.031s) ok 1 - buffer pin conflict: cursor with conflicting pin established
Waiting for replication conn standby's replay_lsn to pass 0/3430000 on primary
done
timed out waiting for match: (?^:User was holding shared buffer pin for too long) at t/031_recovery_conflict.pl line 318.

Perhaps this can simply be attributed to the machine being too busy.

Christoph