Re: Doc: fix the note related to the GUC "synchronized_standby_slots"
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: "Masahiro.Ikeda@nttdata.com" <Masahiro.Ikeda@nttdata.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "Masao.Fujii@nttdata.com" <Masao.Fujii@nttdata.com>,
shveta malik <shveta.malik@gmail.com>
Date: 2024-08-27T03:20:57Z
Lists: pgsql-hackers
On Mon, Aug 26, 2024 at 6:38 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > On Monday, August 26, 2024 5:37 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Mon, Aug 26, 2024 at 1:30 PM <Masahiro.Ikeda@nttdata.com> wrote: > > > > > > When I read the following documentation related to the > > "synchronized_standby_slots", I misunderstood that data loss would not occur > > in the case of synchronous physical replication. However, this is incorrect (see > > reproduce.txt). > > > > > > > Note that in the case of asynchronous 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. > > > https://www.postgresql.org/docs/17/logical-replication-failover.html > > > > > > Am I missing something? > > > > > > > It seems part of the paragraph: "Note that in the case of asynchronous > > 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." is > > a bit confusing. Will it make things clear to me if we remove that part? > > I think the intention is to address a complaint[1] that the date inserted on > primary after the primary disconnects with the standby is still lost after > failover. But after rethinking, maybe it's doesn't directly belong to the topic in > the logical failover section because it's a general fact for async replication. > If we think it matters, maybe we can remove this part and slightly modify > another part: > > parameter ensures a seamless transition of those subscriptions after the > standby is promoted. They can continue subscribing to publications on the > - new primary server without losing data. > + new primary server without losing that has already been replicated and > + flushed on the standby server. > Yeah, we can change that way but not sure if that satisfies the OP's concern. I am waiting for his response. -- With Regards, Amit Kapila.
Commits
-
Doc: Fix the ambiguity in the description of failover slots.
- 9d90e2bdafbd 18.0 landed
- 135007a1008c 17.0 landed