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: <20220726181611.4xw3blxigqzsz4d4@alap3.anarazel.de>
References: <E1nca5h-000nN0-6f@gemulon.postgresql.org>
 <394950.1651077914@sss.pgh.pa.us> <447238.1651082925@sss.pgh.pa.us>
 <2454340.1658858273@sss.pgh.pa.us>
 <20220726181611.4xw3blxigqzsz4d4@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 26 Jul 2022 11:16:11 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2468549.1658860230.1@sss.pgh.pa.us>
Date: Tue, 26 Jul 2022 14:30:30 -0400
Message-ID: <2468550.1658860230@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2468550.1658860230%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2022-07-26 13:57:53 -0400, Tom Lane wrote:
>> So this is not a case of RecoveryConflictInterrupt doing the wrong thing:
>> the startup process hasn't detected the buffer conflict in the first
>> place.

> I wonder if this, at least partially, could be be due to the elog thing
> I was complaining about nearby. I.e. we decide to FATAL as part of a
> recovery conflict interrupt, and then during that ERROR out as part of
> another recovery conflict interrupt (because nothing holds interrupts as
> part of FATAL).

There are all sorts of things one could imagine going wrong in the
backend receiving the recovery conflict interrupt, but AFAICS in these
failures, the startup process hasn't sent a recovery conflict interrupt.
It certainly hasn't logged anything suggesting it noticed a conflict.

			regards, tom lane