Re: Allow logical failover slots to wait on synchronous replication
John H <johnhyvr@gmail.com>
From: John H <johnhyvr@gmail.com>
To: shveta malik <shveta.malik@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, "bertranddrouvot.pg@gmail.com" <bertranddrouvot.pg@gmail.com>,
pgsql-hackers@postgresql.org
Date: 2024-08-26T19:25:51Z
Lists: pgsql-hackers
Hi Shveta, On Sun, Jul 21, 2024 at 8:42 PM shveta malik <shveta.malik@gmail.com> wrote: > > Ah that's a gap. Let me add some logging/warning in a similar fashion. > > Although I think I'd have the warning be relatively generic (e.g. > > changes are blocked because > > they're not synchronously committed) > > > > okay, sounds good. > > thanks > Shveta I took a look at having similar warnings the existing 'synchronized_standby_slots' feature has and I don't think it's particularly feasible. The checks/warnings for 'synchronized_standby_slots' are intended to protect against misconfiguration. They consist of slot validation (valid slot_name, not logical slot, slot has not been invalidated), and whether or not the slot is active. I don't think there's a "misconfiguration" equivalent for waiting on synchronous_commit. With the current proposal, once you have (synchronous_commit enabled && failover_slots), logical decoding is dependent on whether or not the writes have been replicated to a synchronous replica. If there is no data being replicated out of the logical slot, it is because from the perspective of the database no writes have been committed yet. I don't think it would make sense to add logging/warning as to why a transaction is still not committed (e.g. which potential replica is the one lagging). There isn't a nice way to determine why synchronous commit is waiting without being particularly invasive, and even then it could be particularly noisy (e.g. provide all the application_names that we are potentially waiting on). Thanks, -- John Hsu - Amazon Web Services