Re: Doc: fix the note related to the GUC "synchronized_standby_slots" - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Doc: fix the note related to the GUC "synchronized_standby_slots"
Date
Msg-id CAA4eK1JatP82xHm4kKSgUhRS=G2qRPAkzRbgkO-irifpsT5mSw@mail.gmail.com
Whole thread Raw
In response to RE: Doc: fix the note related to the GUC "synchronized_standby_slots"  (<Masahiro.Ikeda@nttdata.com>)
Responses RE: Doc: fix the note related to the GUC "synchronized_standby_slots"
List pgsql-hackers
On Tue, Aug 27, 2024 at 3:05 PM <Masahiro.Ikeda@nttdata.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.)

>
 Additionally, in the case of asynchronous physical replication,
> there remains a risk of data loss for transactions committed on the former primary server
> but have yet to be replicated to the new primary server.
>

This has nothing to do with failover slots. This is a known behavior
of asynchronous replication, so adding here doesn't make much sense.

In general, adding more information unrelated to failover slots can
confuse users.

[1] - https://www.postgresql.org/docs/17/runtime-config-replication.html#GUC-SYNCHRONIZED-STANDBY-SLOTS

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: Parallel CREATE INDEX for GIN indexes
Next
From: Tomas Vondra
Date:
Subject: Re: Parallel CREATE INDEX for GIN indexes