On Tue, Nov 21, 2023 at 4:35 PM Drouvot, Bertrand
<bertranddrouvot.pg@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.malik@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.
