On Wed, Jan 24, 2024 at 2:43 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Jan 24, 2024 at 10:41 AM Masahiko Sawada <sawada.m...@gmail.com> > wrote: > > > > On Mon, Jan 22, 2024 at 3:58 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > Can we think of using GetStandbyFlushRecPtr()? We probably need to > > > expose this function, if this works for the required purpose. > > > > GetStandbyFlushRecPtr() seems good. But do we really want to raise an > > ERROR in this case? IIUC this case could happen often when the slot > > used by the standby is not listed in standby_slot_names. > > > > or it can be due to some bug in the code as well. > > > I think we > > can just skip such a slot to synchronize and check it the next time. > > > > How about logging the message and then skipping the sync step? This > will at least make users aware that they could be missing to set > standby_slot_names.
+1 > > > Here are random comments on slotsyncworker.c (v66): > > > > +/* GUC variable */ > > +bool enable_syncslot = false; > > > > Is enable_syncslot a really good name? We use "enable" prefix only for > > planner parameters such as enable_seqscan, and it seems to me that > > "slot" is not specific. Other candidates are: > > > > * synchronize_replication_slots = on|off > > * synchronize_failover_slots = on|off > > > > I would prefer the second one. Would it be better to just say > sync_failover_slots? Works for me. But if we want to extend this option for non-failover slots as well in the future, synchronize_replication_slots (or sync_replication_slots) seems better. We can extend it by having an enum later. For example, the values can be on, off, or failover etc. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
