Re: Doc: fix the note related to the GUC "synchronized_standby_slots"
От | Amit Kapila |
---|---|
Тема | Re: Doc: fix the note related to the GUC "synchronized_standby_slots" |
Дата | |
Msg-id | CAA4eK1JatP82xHm4kKSgUhRS=G2qRPAkzRbgkO-irifpsT5mSw@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Doc: fix the note related to the GUC "synchronized_standby_slots" (<Masahiro.Ikeda@nttdata.com>) |
Ответы |
RE: Doc: fix the note related to the GUC "synchronized_standby_slots"
|
Список | 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 по дате отправления: