Re: Doc: fix the note related to the GUC "synchronized_standby_slots"

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

In response to

Responses

Browse pgsql-hackers by date

  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