On Tue, Aug 27, 2024 at 12:56 AM John H <johnh...@gmail.com> wrote: > > 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). >
Okay. Thanks for the details. I see your point. I will review to see if anything comes to my mind for a simpler way to do this. thanks Shveta
