On Tue, Aug 27, 2024 at 12:56 AM John H <johnhyvr@gmail.com> wrote:
>
> 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).
>
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
