On Friday, February 2, 2024 2:56 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Feb 1, 2024 at 5:29 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Thu, Feb 1, 2024 at 2:35 PM Amit Kapila <amit.kapila16@gmail.com>
> wrote:
> > >
> > > Agreed, and I am fine with merging 0001, 0002, and 0004 as suggested
> > > by you though I have a few minor comments on 0002 and 0004. I was
> > > thinking about what will be a logical way to split the slot sync
> > > worker patch (combined result of 0001, 0002, and 0004), and one idea
> > > occurred to me is that we can have the first patch as
> > > synchronize_solts() API and the functionality required to implement
> > > that API then the second patch would be a slot sync worker which
> > > uses that API to synchronize slots and does all the required validations.
> > > Any thoughts?
> >
> > If we shift 'synchronize_slots()' to the first patch but there is no
> > caller of it, we may have a compiler warning for the same. The only
> > way it can be done is if we temporarily add SQL function on standby
> > which uses 'synchronize_slots()'. This SQL function can then be
> > removed in later patches where we actually have a caller for
> > 'synchronize_slots'.
> >
>
> Can such a SQL function say pg_synchronize_slots() which can sync all slots that
> have a failover flag set be useful in general apart from just writing tests for this
> new API? I am thinking maybe users want more control over when to sync the
> slots and write their bgworker or simply do it just before shutdown once (sort
> of planned switchover) or at some other pre-defined times. BTW, we also have
> pg_log_standby_snapshot() which otherwise would be done periodically by
> background processes.
Here is an attempt for this. The slotsync worker patch is now splitted into
two patches(0002 and 0003). I also adjusted the doc, comments and tests for the
new pg_synchronize_slots() function.
Best Regards,
Hou zj