From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Thomas Munro <thomas.munro@gmail.com>,
        Melanie Plageman <melanieplageman@gmail.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Unstable tests for recovery conflict handling
In-reply-to: <394950.1651077914@sss.pgh.pa.us>
References: <E1nca5h-000nN0-6f@gemulon.postgresql.org> <394950.1651077914@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 27 Apr 2022 12:45:14 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <447237.1651082925.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Apr 2022 14:08:45 -0400
Message-ID: <447238.1651082925@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/447238.1651082925%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> It's been kind of hidden by other buildfarm noise, but
> 031_recovery_conflict.pl is not as stable as it should be [1][2][3][4].
> ...
> I think this is showing us a real bug, ie we sometimes fail to cancel
> the conflicting query.

After digging around in the code, I think this is almost certainly
some manifestation of the previously-complained-of problem [1] that
RecoveryConflictInterrupt is not safe to call in a signal handler,
leading the conflicting backend to sometimes decide that it's not
the problem.  That squares with the observation that skink is more
prone to show this than other animals: you'd have to get the SIGUSR1
while the target backend isn't idle, so a very slow machine ought to
show it more.  We don't seem to have that issue on the open items
list, but I'll go add it.

Not sure if the 'buffer pin conflict: stats show conflict on standby'
failure could trace to a similar cause.

			regards, tom lane

[1] https://www.postgresql.org/message-id/flat/CA%2BhUKGK3PGKwcKqzoosamn36=
YW-fsuTdOPPF1i_rtEO%3DnEYKSg%40mail.gmail.com