Hi, On Fri, Feb 02, 2024 at 12:25:30PM +0530, Amit Kapila wrote: > On Thu, Feb 1, 2024 at 5:29 PM shveta malik <shveta.ma...@gmail.com> wrote: > > > > On Thu, Feb 1, 2024 at 2:35 PM Amit Kapila <amit.kapil...@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.
Big +1 for having this kind of function in user's hands (as the standby's slots may be lagging behind during a switchover for example). As far the name, I think it would make sense to add "replication" or "repl" something like pg_sync_replication_slots()? (that would be aligned with pg_create_logical_replication_slot() and friends). > BTW, we also have > pg_log_standby_snapshot() which otherwise would be done periodically > by background processes. > > > > > 1) Re-arranged the patches: > > 1.1) 'libpqrc' related changes (from v74-001 and v74-004) are > > separated out in v75-001 as those are independent changes. > > Bertrand, Sawada-San, and others, do you see a problem with such a > split? Can we go ahead with v75_0001 separately after fixing the open > comments? I think that makes sense, specially if we're also creating a user callable function to sync the slot(s) at wish. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com