From: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
---|---|
To: | John H <johnhyvr(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "bertranddrouvot(dot)pg(at)gmail(dot)com" <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, shveta malik <shveta(dot)malik(at)gmail(dot)com> |
Subject: | Re: Allow logical failover slots to wait on synchronous replication |
Date: | 2024-08-28 03:16:21 |
Message-ID: | CAJpy0uBww2o25hNS6syoOotPF9HCL2sB2iSZ46vW_J+4noCmDg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 27, 2024 at 12:56 AM John H <johnhyvr(at)gmail(dot)com> wrote:
>
> Hi Shveta,
>
> On Sun, Jul 21, 2024 at 8:42 PM shveta malik <shveta(dot)malik(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | shveta malik | 2024-08-28 03:30:17 | Re: Conflict detection and logging in logical replication |
Previous Message | Craig Ringer | 2024-08-28 02:24:45 | Re: RFC: Additional Directory for Extensions |