| 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: | Whole Thread | Raw Message | 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 |