Hi Shveta, On Sun, Jul 21, 2024 at 8:42 PM shveta malik <shveta.ma...@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