Message-ID: <eb1a5570-ecc4-42c4-b944-d1b6e95090e7@iki.fi>
Date: Wed, 11 Mar 2026 00:10:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Refactor recovery conflict signaling a little
To: Xuneng Zhou <xunengzhou@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
 Chao Li <li.evan.chao@gmail.com>
References: <4cc13ba1-4248-4884-b6ba-4805349e7f39@iki.fi>
 <EA619211-93E3-40BF-8EC0-AED29B87AC33@gmail.com>
 <81b2c9a1-6d75-4ba9-894c-fd66c9036d99@iki.fi>
 <70774903-9f03-4816-b008-e2002a652bb9@iki.fi>
 <c776c784-695a-4357-b788-f4d3ca5c5fa1@gmail.com>
 <1f354762-c6a8-46a5-9626-efeb45f5f112@iki.fi>
 <25f20e5b-786e-42c2-9f0c-b253742ddbf5@gmail.com>
 <CABPTF7X5+fQ6kOesnk1Q7g3cgz858CYMkbk-oUNGzDS1bb6F4Q@mail.gmail.com>
 <3e07149d-060b-48a0-8f94-3d5e4946ae45@gmail.com>
 <54f60f3f-3a77-4e99-b2d5-99c5e32e6a75@iki.fi>
 <CABPTF7W8ORcdhSeRLhjV4M8JKEF65QXm9Z=cv-vchXn0C1gvAQ@mail.gmail.com>
 <f3316196-1a9e-4f70-a484-a8d5bb2cc235@iki.fi>
 <CABPTF7UrmAPu_O8TN0igg16C5LWMF9k0LObcbKqggeNLZoAUCQ@mail.gmail.com>
 <CABPTF7UhV+OkAK9AAFERP6+U7=2OMJ0QGtEYYN9j=WhPRZxdQg@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CABPTF7UhV+OkAK9AAFERP6+U7=2OMJ0QGtEYYN9j=WhPRZxdQg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/eb1a5570-ecc4-42c4-b944-d1b6e95090e7%40iki.fi>
Precedence: bulk

On 10/03/2026 05:55, Xuneng Zhou wrote:
> On Tue, Mar 10, 2026 at 1:05 AM Xuneng Zhou <xunengzhou@gmail.com> wrote:
>>
>> On Mon, Mar 9, 2026 at 11:28 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>>
>>> On 09/03/2026 17:02, Xuneng Zhou wrote:
>>>> 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.
>>>
>>> I used the attached, to be precise. With that it fails every time for
>>> me. I'm not sure if the "if (am_walsender)" check is necessary, I added
>>> it just to make the test run faster.
>>>
>>> - Heikki
>>
>> I was able to reproduce the issue using a wider sleep window as you
>> suggested and can confirm that the flag is not cleared after applying
>> the patch. Below are two logs—one from a successful run and one from a
>> failed run. I'll look further into the patch later on.
>>
>> failed run:
>> startup[1418915] LOG:  DBG SignalRecoveryConflict target_pid=1419118
>> reason=4 old_mask=0x0 new_mask=0x10
>> walsender[1419118] LOG:  DBG ProcArrayEndTransaction(no-xid) CLEARING
>> pendingRecoveryConflicts=0x10
>>
>> successful run:
>> startup[1433218] LOG:  DBG SignalRecoveryConflict target_pid=1433406
>> reason=4 old_mask=0x0 new_mask=0x10
>> walsender[1433406] LOG:  DBG ProcessInterrupts handler fired 1
>> time(s), pending=0x10 -- processing
>> walsender[1433406] ERROR:  canceling statement due to conflict with recovery
> 
> I ran the script several times after applying the patch, and all tests
> passed without deadlocking. LGTM.

Ok, thanks for confirming! Pushed.

> One nit: should we separate the comment fix and the
> InitAuxiliaryProcess hardening into separate patches?

I think it's appropriate to include them here; they're also follow-up 
fixes for the same commit 17f51ea818.

- Heikki