Hi Heikki,
On Mon, Mar 9, 2026 at 7:17 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> On 07/03/2026 13:00, Alexander Lakhin wrote:
> > Hello Xuneng and Heikki,
> >
> > 04.03.2026 07:33, Xuneng Zhou wrote:
> >>> 03.03.2026 17:39, Heikki Linnakangas wrote:
> >>>> On 24/02/2026 10:00, Alexander Lakhin wrote:
> >>>>> The "terminating process ..." message doesn't appear when the test passes
> >>>>> successfully.
> >>>> Hmm, right, looks like something wrong in signaling the recovery conflict. I can't tell if the signal is being
sent,
> >>>> or it's not processed correctly. Looking at the code, I don't see anything wrong.
> >>>>
> >> I was unable to reproduce the issue on an x86_64 Linux machine using
> >> the provided script. All test runs completed successfully without any
> >> failures.
> >
> > I've added debug logging (see attached) and saw the following:
> > !!!SignalRecoveryConflict[282363]
> > !!!ProcArrayEndTransaction| pendingRecoveryConflicts = 0
> > !!!ProcessInterrupts[283863]| MyProc->pendingRecoveryConflicts: 0
> > !!!ProcessInterrupts[283863]| MyProc->pendingRecoveryConflicts: 0
> > 2026-03-07 12:21:24.544 EET walreceiver[282421] FATAL: could not
> > receive data from WAL stream: server closed the connection unexpectedly
> > This probably means the server terminated abnormally
> > before or while processing the request.
> > 2026-03-07 12:21:24.645 EET postmaster[282355] LOG: received immediate
> > shutdown request
> > 2026-03-07 12:21:24.647 EET postmaster[282355] LOG: database system is
> > shut down
>
> A-ha! So MyProc->pendingRecoveryConflicts is being cleared by
> ProcArrayEndTransaction(). If I add a small pg_usleep() to the top of
> ProcArrayEndTransaction(), I can readily reproduce this.
>
> Thanks for narrowing this down. The attached patch fixes it.
>
> - Heikki
Did you use Alexander’s reproducer script? I tried reproducing with a
1 ms pg_usleep() added to all three functions that clear
MyProc->pendingRecoveryConflicts, but I still couldn’t reproduce the
issue.
--
Best,
Xuneng
