public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ashutosh Sharma <[email protected]>
To: Hsu, John <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Synchronizing slots from primary to standby
Date: Fri, 4 Feb 2022 23:21:24 +0530
Message-ID: <CAE9k0PnurnLWjQx68sUrv55B9GtAD5ZeG1bDgF0ueC-TpX3Mrg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CAD21AoBy9q0ELpe8-x6K2k4od-1ggY_Sx-_H88J=G7=vL0X2Zg@mail.gmail.com>
<[email protected]>
On Sat, Jan 22, 2022 at 4:33 AM Hsu, John <[email protected]> wrote:
>
> > I might be missing something but isn’t it okay even if the new primary
> > server is behind the subscribers? IOW, even if two slot's LSNs (i.e.,
> > restart_lsn and confirm_flush_lsn) are behind the subscriber's remote
> > LSN (i.e., pg_replication_origin.remote_lsn), the primary sends only
> > transactions that were committed after the remote_lsn. So the
> > subscriber can resume logical replication with the new primary without
> > any data loss.
>
> Maybe I'm misreading, but I thought the purpose of this to make
> sure that the logical subscriber does not have data that has not been
> replicated to the new primary. The use-case I can think of would be
> if synchronous_commit were enabled and fail-over occurs. If
> we didn't have this set, isn't it possible that this logical subscriber
> has extra commits that aren't present on the newly promoted primary?
>
This is very much possible if the new primary used to be asynchronous
standby. But, it seems like the current patch is trying to hold the
logical replication until the data has been replicated to the physical
standby when synchronous_slot_names is set. This will ensure that the
logical subscriber is never ahead of the new primary. However, AFAIU
that's not the primary use-case of this patch; instead this is to
ensure that the logical subscribers continue getting data from the new
primary when the failover occurs.
>
> If a logical slot was dropped on the writer, should the worker drop logical
> slots that it was previously synchronizing but are no longer present? Or
> should we leave that to the user to manage? I'm trying to think why users
> would want to sync logical slots to a reader but not have that be dropped
> as well if it's no longer present.
>
AFAIU this should be taken care of by the background worker used to
synchronize the replication slot.
--
With Regards,
Ashutosh Sharma.
view thread (4+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Synchronizing slots from primary to standby
In-Reply-To: <CAE9k0PnurnLWjQx68sUrv55B9GtAD5ZeG1bDgF0ueC-TpX3Mrg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox