On Tue, Nov 21, 2023 at 4:35 PM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: > > On 11/21/23 10:32 AM, shveta malik wrote: > > On Tue, Nov 21, 2023 at 2:02 PM shveta malik <shveta.ma...@gmail.com> wrote: > >> > > > v37 fails to apply to HEAD due to a recent commit e83aa9f92fdd, > > rebased the patches. PFA v37_2 patches. > > Thanks! > > Regarding the promotion flow: If the primary is available and reachable I > don't > think we currently try to ensure that slots are in sync. I think we'd miss the > activity since the last sync and the promotion request or am I missing > something? > > If the primary is available and reachable shouldn't we launch a last round of > synchronization (skipping all the slots that are not in 'r' state)? >
We may miss the last round but there is no guarantee that we can ensure to sync of everything if the primary is available. Because after our last sync, there could probably be some more activity. I think it is the user's responsibility to promote a new primary when the old one is not required for some reason. It is not only slots that can be out of sync but even we can miss fetching some of the data. I think this is quite similar to what we do for WAL where on finding the promotion signal, we shut down Walreceiver and just replay any WAL that was already received by walreceiver. Also, the promotion shouldn't create any problem w.r.t subscribers connecting to the new primary because the slot's position is slightly behind what could be requested by subscribers which means the corresponding data will be available on the new primary. Do you have something in mind that can create any problem if we don't attempt additional fetching round after the promotion signal is received? -- With Regards, Amit Kapila.
