Hi Michael, On Thu, Jun 11, 2026 at 9:15 AM Michael Paquier <[email protected]> wrote: > > On Wed, Jun 10, 2026 at 05:28:00PM +0000, Bertrand Drouvot wrote: > > On Wed, Jun 10, 2026 at 04:36:14PM +0800, Xuneng Zhou wrote: > >> The > >> essential thing is just to ensure that the startup remains paused > >> until decoding output is observed. > > > > Right, thanks for confirming. That's exactly what v2 is doing. > > I have looked at this thread, and my first impression was that this > could be a data integrity issue while decoding changes due to the > transient errors one could see across the promotion requests. > > But it's less severe than I thought initially: we have an availability > problem here, down to v16, with a correct recovery possible once the > promotion request has completed. That could be indeed surprising for > users that have HA setups with standbys doing logical decoding.. The > SQL function path is less worrying to me, there are as far as I know > few users of it compared to the "native" path with sync workers. > > read_local_xlog_page_guts() does not only impact SQL-callable logirep > functions, even it is the spot that should be hit most of the time > (again, the RecoveryInProgress() vs promotion window is super narrow). > At quick glance, things are: > - walinspect. > - Slot advance. > - Slot creation (?), but it feels even narrower.
Yeah, it is used for two-phase commit as well. The usage of it is broader than I observed before. Repack worker also make use of it. > With two items dealt with on this thread for these two callback paths > changed, moving on the part related to physical replication into its > own thread would be better. This requires an entirely different > analysis and a different lookup. +1 > The backpatch of PG16 is straight-forward and adding > GetWALInsertionTimeLineIfSet() down there does not look like an issue. > Not having any tests in v16 feels sad, but that's life. It does not > prevent addressing the availability issue on this branch. > > I'll go take it up from here. > -- Thanks for dealing with this! -- Regards, Xuneng Zhou HighGo Software Co., Ltd.
