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 ZNJKwdzW0QUyd0Vc@msg.df7cb.de
Whole thread Raw
In response to Re: A failure in 031_recovery_conflict.pl on Debian/s390x  (Andres Freund <andres@anarazel.de>)
Responses Re: A failure in 031_recovery_conflict.pl on Debian/s390x
List pgsql-hackers
Re: Andres Freund
> Hm, that could just be a "harmless" race. Does it still happen if you apply
> the attached patch in addition?

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.

But admittedly, this build machine is quite sluggish at times, likely
due to neighboring VMs on the same host. (Perhaps that even explains
the behavior from before this patch.) I'll still attach the logs since
I frankly can't judge what errors are acceptable here and which
aren't.

Christoph

Attachment

pgsql-hackers by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: 2023-08-10 release announcement draft
Next
From: Ashutosh Bapat
Date:
Subject: Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning