From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Masahiro(dot)Ikeda(at)nttdata(dot)com |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Masao(dot)Fujii(at)nttdata(dot)com |
Subject: | Re: Doc: fix the note related to the GUC "synchronized_standby_slots" |
Date: | 2024-08-28 09:00:13 |
Message-ID: | CAA4eK1JbFnSpebnd4pzkEJPWt=VspBgHpa+jGy6ks=knJk1gpg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 28, 2024 at 6:16 AM <Masahiro(dot)Ikeda(at)nttdata(dot)com> wrote:
>
> > > > So, will it be okay if we just remove ".. without losing data" from
> > > > the sentence? Will that avoid the confusion you have?
> > > Yes. Additionally, it would be better to add notes about data
> > > consistency after failover for example
> > >
> > > Note that data consistency after failover can vary depending on the
> > > configurations. If "synchronized_standby_slots" is not configured,
> > > there may be data that only the subscribers hold, even though the new primary does
> > not.
> > >
> >
> > This part can be inferred from the description of synchronized_standby_slots [1] (See:
> > This guarantees that logical replication failover slots do not consume changes until those
> > changes are received and flushed to corresponding physical standbys. If a logical
> > replication connection is meant to switch to a physical standby after the standby is
> > promoted, the physical replication slot for the standby should be listed here.)
>
> OK, it's enough for me just remove ".. without losing data".
>
The next line related to asynchronous replication is also not
required. See attached.
--
With Regards,
Amit Kapila.
Attachment | Content-Type | Size |
---|---|---|
fix_doc_1.patch | application/octet-stream | 810 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2024-08-28 09:01:22 | Re: [PATCH] Support systemd readiness notifications on reload |
Previous Message | Alexander Lakhin | 2024-08-28 09:00:00 | Re: Streaming read-ready sequential scan code |