Re: Synchronizing slots from primary to standby

On Wed, Jul 26, 2023 at 5:55 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Mon, Jul 24, 2023 at 8:03 AM Bharath Rupireddy
> <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> >
> > On Fri, Jul 21, 2023 at 5:16 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> > >
> > > Thanks Bharat for letting us know. It is okay to split the patch, it
> > > may definitely help to understand the modules better but shall we take
> > > a step back and try to reevaluate the design first before moving to
> > > other tasks?
> >
> > Agree that design comes first. FWIW, I'm attaching the v9 patch set
> > that I have with me. It can't be a perfect patch set unless the design
> > is finalized.
> >
>
> Thanks for the patch and summarizing all the issues here. I was going
> through the patch and found that now we need to maintain
> 'synchronize_slot_names' on both primary and standby unlike the old
> way where it was maintained only on standby. I am aware of the problem
> in earlier implementation where each logical walsender/slot needed to
> wait for all standbys to catch-up before sending changes to logical
> subscribers even though that particular slot is not even needed to be
> synced by any of the standbys. Now it is more restrictive. But now, is
> this 'synchronize_slot_names' per standby? If there are multiple
> standbys each having different 'synchronize_slot_names' requirements,
> then how primary is going to keep track of that?
> Please let me know if that scenario can never arise where standbys can
> have different 'synchronize_slot_names'.
>

Can we think of sending 'synchronize_slot_names' from standby to
primary at the time of connection? I think we also need to ensure that
if the user changes this value then we need to restart the sync slot
worker to allow this information to be sent to the primary. We do
something similar for apply worker in logical replication.

--
With Regards,
Amit Kapila.