Re: Refactor recovery conflict signaling a little
Xuneng Zhou <xunengzhou@gmail.com>
From: Xuneng Zhou <xunengzhou@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Alexander Lakhin <exclusion@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Chao Li <li.evan.chao@gmail.com>
Date: 2026-03-09T17:05:26Z
Lists: pgsql-hackers
Attachments
- 035_standby_logical_decoding_standby_success.log (application/octet-stream)
- 035_standby_logical_decoding_standby_failure.log (application/octet-stream)
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 -- Best, Xuneng
Commits
-
Don't clear pendingRecoveryConflicts at end of transaction
- 138592d1b066 19 (unreleased) landed
-
Refactor ProcessRecoveryConflictInterrupt for readability
- be5257725d7f 19 (unreleased) landed
-
Separate RecoveryConflictReasons from procsignals
- 17f51ea81875 19 (unreleased) landed
-
Use ProcNumber rather than pid in ReplicationSlot
- ddc3250208bd 19 (unreleased) landed
-
Don't hint that you can reconnect when the database is dropped
- 57bff90160fd 19 (unreleased) landed
-
Remove useless errdetail_abort()
- cd375d5b6d5f 19 (unreleased) landed
-
Teach standby conflict resolution to use SIGUSR1
- a8ce974cddef 9.0.0 cited