From: | Perumal Raj <perucinci(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | shveta malik <shveta(dot)malik(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Resolved: Logical Replication slot disappeared after promote Standby |
Date: | 2025-06-14 08:08:50 |
Message-ID: | CALvqh4ooMqtigL+aP5Pb+eu6wnMxsTxkni_N+-5DsDKj58dbOA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 13, 2025 at 9:46 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, Jun 13, 2025 at 10:52 PM Perumal Raj <perucinci(at)gmail(dot)com> wrote:
> >
> > Thanks for explanation Shveta!
> >
> > ------------
> > As Summary in this original thread,
> >
> > Prerequisites for Setting Up a Logical Replication Slot sync in >= pg17
> >
> > To successfully configure a logical replication slot, ensure the
> following settings are applied:
> >
> > wal_level = 'logical'
> > hot_standby = 'on'
> > hot_standby_feedback = 'on'
> > sync_replication_slots = 'on'
> >
>
> Additionally, you need to configure primary_slot_name on the standby
> and have dbname in primary_conninfo. For further details, you can
> refer docs (1)(2).
>
*Thanks for the notes here. *
*Yes, those parameters configured as part of Normal Physical replication
setup. *
> > Replication Slot Synchronization
> >
> > Logical replication slots can synchronize with all direct standby
> servers of the primary but are not compatible with cascade standby servers.
> >
> > Temporary Status of New Standby Slots
> >
> > If a new standby server is created after the logical replication slot,
> it will be marked as temporary=true until the reset_lsn of the primary
> matches the confirmed_lsn of the new standby.
> >
>
> It is restart_lsn on both nodes, but there are other things like
> slot's catalog_xmin as well. As a user, you need to ensure that your
> primary's logical slot is being consumed. And this is required
> primarily at the initial sync time so that we sync the slot only if
> the standby has required resources like WAL to allow decoding from the
> synced slot after failover.
>
*Thanks for correcting,*
> > Limitations on Using Logical Replication Slots
> >
> > While logical replication slots can synchronize on the direct standby
> side, they cannot be utilized (as in the case of Debezium) until the
> standby server is promoted to primary. Attempting to use a synchronized
> logical slot on a standby server will result in the following error:
> >
> > org.postgresql.util.PSQLException: ERROR: cannot use replication slot
> "kafka_logical_slot" for logical decoding
> > Detail: This replication slot is being synchronized from the primary
> server.
> >
>
> I don't think we can call this a limitation. According to me, this is
> a requirement for this feature to work. Consider if we allow the use
> of this synced slot for decoding when sync is still in-progress, this
> slot could be advanced ahead of the primary. Now, after the failover,
> we won't be able to reuse this slot to allow the subscribers to
> continue replication.
>
*Make sense, *
> (1) -
> https://www.postgresql.org/docs/devel/logicaldecoding-explanation.html#LOGICALDECODING-REPLICATION-SLOTS-SYNCHRONIZATION
> (2) -
> https://www.postgresql.org/docs/devel/logical-replication-failover.html
>
> --
> With Regards,
> Amit Kapila.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Perumal Raj | 2025-06-14 08:35:05 | pglogical3 : support |
Previous Message | Fujii Masao | 2025-06-14 07:05:36 | Re: pg_dump --with-* options |