From: | <Masahiro(dot)Ikeda(at)nttdata(dot)com> |
---|---|
To: | <amit(dot)kapila16(at)gmail(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 00:46:12 |
Message-ID: | OS3PR01MB63908E3F8530F7197523C42FB1952@OS3PR01MB6390.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > 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".
> >
> 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.
OK, I agreed to remove the sentence.
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2024-08-28 01:15:33 | Re: Parallel CREATE INDEX for GIN indexes |
Previous Message | Matthias van de Meent | 2024-08-28 00:40:47 | Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans) |