public inbox for [email protected]
help / color / mirror / Atom feedFrom: shveta malik <[email protected]>
To: John H <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: [email protected] <[email protected]>
Cc: [email protected]
Cc: shveta malik <[email protected]>
Subject: Re: Allow logical failover slots to wait on synchronous replication
Date: Wed, 28 Aug 2024 08:46:21 +0530
Message-ID: <CAJpy0uBww2o25hNS6syoOotPF9HCL2sB2iSZ46vW_J+4noCmDg@mail.gmail.com> (raw)
In-Reply-To: <CA+-JvFu2ke5Ta8DdoRhSu+Aw6CfjYatX_kEWTsKRc0N1uCrLdw@mail.gmail.com>
References: <CA+-JvFtq6f7+wAwSdud-x0yMTeMejUhpkyid1Xa_VNpRd_-oPw@mail.gmail.com>
<CAA4eK1+5H4wUCg3afO=Jc_mHCCwGCadH0SxxXR=SQAPCBGcRuA@mail.gmail.com>
<CA+-JvFsn_FMKVcbztr2LiVKzwjz6uQTNKtakR47mXg+78Nt2iA@mail.gmail.com>
<CAJpy0uCZ04ZQFHs-tV5LprkYtSSwtBtUJW4O=0S01yc+TRw7EQ@mail.gmail.com>
<CAJpy0uAkMajFvc9t1BtPwRu8PqqrKbg-OG0DLYFd9NC3dCa_Ag@mail.gmail.com>
<CA+-JvFvwj1j8L0TfnfB8ddCxcbFcp_DeOs-oGiWS+o8warmh9w@mail.gmail.com>
<CAJpy0uC313+_Z_cxm94AggjsDCuKFjYRviTiBWs5WaWDFmmq+A@mail.gmail.com>
<CA+-JvFu2ke5Ta8DdoRhSu+Aw6CfjYatX_kEWTsKRc0N1uCrLdw@mail.gmail.com>
On Tue, Aug 27, 2024 at 12:56 AM John H <[email protected]> wrote:
>
> Hi Shveta,
>
> On Sun, Jul 21, 2024 at 8:42 PM shveta malik <[email protected]> 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
view thread (8+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Allow logical failover slots to wait on synchronous replication
In-Reply-To: <CAJpy0uBww2o25hNS6syoOotPF9HCL2sB2iSZ46vW_J+4noCmDg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox