Re: Using failover slots for PG-non_PG logical replication

On Fri, Jul 4, 2025 at 9:23 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> >
> > How about this:
> > We change the following sentence in the third paragraph
> > To confirm that the standby server is indeed ready for failover <new
> > addition> so that a given PostgreSQL subscriber can continue logical
> > replication </new addition>, follow ... . <new addition> A
> > non-PostgreSQL downstream may need to device a different way to find
> > the slots corresponding to its subscriptions or use the next section.
> >
> > Then add a separate paragraph at the end or a separate section like below.
> >
> > In order to check whether a standby server is ready for failover so
> > that all the subscribers, PostgreSQL as well as non-PostgreSQL, can
> > continue logical replication, follow these steps make sure that all
> > the replication slots, on the primary server, that have property
> > failover = true are synchronized to the standby server.
> > 1. On the primary server run following query
> > select slot_name from pg_replication_slots where failover and NOT temporary
> >
> > 2. Check that the logical replication slots identified above exist on
> > the standby server and are ready for failover.
> > SELECT slot_name, (synced AND NOT temporary AND NOT conflicting) AS
> > failover_ready
> >                FROM pg_replication_slots
> >                WHERE slot_name IN
> >
> > Does that look good?
> >
>
> Yes, something on these lines sounds like an improvement. Would you
> like to propose a patch or want Shveta or me to do the same?

How about something like attached.

I couldn't figure out whether the query on primary to fetch all the
slots to be synchronized should filter based on invalidation_reason
and conflicting or not. According to synchronize_slots(), it seems
that we retain invalidated slots on standby when failover = true and
they would remain with synced = true on standby. Is that right?

-- 
Best Wishes,
Ashutosh Bapat