Re: Refactor recovery conflict signaling a little

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>
Subject: Re: Refactor recovery conflict signaling a little
Date: 2026-03-09 11:17:40
Message-ID: 54f60f3f-3a77-4e99-b2d5-99c5e32e6a75@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
0001-Don-t-clear-pendingRecoveryConflicts-at-end-of-trans.patch text/x-patch 3.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2026-03-09 11:21:03 Re: pg_stat_replication.*_lag sometimes shows NULL during active replication
Previous Message Shin Berg 2026-03-09 11:02:56 Re: Inconsistency in owner assignment between INDEX and STATISTICS