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

From Christoph Berg
Subject Re: A failure in 031_recovery_conflict.pl on Debian/s390x
Date
Msg-id ZNNwxgIwKkp+i3Zf@msg.df7cb.de
Whole thread Raw
In response to Re: A failure in 031_recovery_conflict.pl on Debian/s390x  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: A failure in 031_recovery_conflict.pl on Debian/s390x
Re: A failure in 031_recovery_conflict.pl on Debian/s390x
List pgsql-hackers
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
line318.
 
> 
> 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

Attachment

pgsql-hackers by date:

Previous
From: GF
Date:
Subject: Re: Adding a pg_servername() function
Next
From: Alvaro Herrera
Date:
Subject: Re: cataloguing NOT NULL constraints