On Mon, Jun 8, 2026 at 10:22 PM Bertrand Drouvot <[email protected]> wrote: > > Hi, > > On Mon, Jun 08, 2026 at 09:00:17PM +0800, Xuneng Zhou wrote: > > I tweaked the reproducer based on the theory outlined above. The main > > changes from the original reproducer are: > > > > 1) blocks at logical-walsender-after-slot-acquire in walsender.c, > > before the decoding context is created and before the reader starts > > from restart_lsn, matching the delay set by Alexander > > > 2) Forces the first read to occur during promotion. It inserts rows > > 1..4, waits for replay, starts promotion with pg_promote(false), holds > > startup at startup-logical-decoding-status-change-end-of-recovery, > > then wakes the walsender. > > Yeah, so this existing startup-logical-decoding-status-change-end-of-recovery > injection point already exists in the code tree and is also called after > CleanupAfterArchiveRecovery() and before RECOVERY_STATE_DONE change in > StartupXLOG(). > > So this is the same window as the new injection point that was added in the > new > tests in v1-0002 shared up-thread [1]. > > That said, I think I prefer the v1-0002 shared up-thread [1] approach for the > tests as: > > - the injection point name clearly describes the tested condition > - no new injection point is added in walsender.c (it pauses startup > mid-promotion > and lets the walsender connect) > - the test relies on one injection point (not two) > > [1]: https://postgr.es/m/aiaBtENl7tTf2MM8%40bdtpg >
Thanks for the clarification. I haven't reviewed the patch set other than applying the patch 1 yet, but I plan to do so tomorrow. -- Regards, Xuneng Zhou HighGo Software Co., Ltd.
