public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nathan Bossart <[email protected]>
To: Bharath Rupireddy <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Cc: SATYANARAYANA NARLAPURAM <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Allow async standbys wait for sync replication
Date: Fri, 4 Mar 2022 11:56:02 -0800
Message-ID: <20220304195602.GA1184024@nathanxps13> (raw)
In-Reply-To: <CALj2ACULc_2TbC44fdFbpPCJ-AmvixdLY9z=LgMfz07QXx9-bg@mail.gmail.com>
References: <20220228185732.GB944837@nathanxps13>
<CALj2ACVNxtGatZKaZm12z8YpUkUW7zewALZJu0iuhGV9Q1ygjA@mail.gmail.com>
<20220301060528.GA1026683@nathanxps13>
<[email protected]>
<20220301170537.GA1031413@nathanxps13>
<CALj2ACUdNd=vVTOdz=UMuWxTVJgzsCUhOwJ6mMsXK150Ec-QOQ@mail.gmail.com>
<20220301212700.GB1033258@nathanxps13>
<CALj2ACULc_2TbC44fdFbpPCJ-AmvixdLY9z=LgMfz07QXx9-bg@mail.gmail.com>
On Wed, Mar 02, 2022 at 09:47:09AM +0530, Bharath Rupireddy wrote:
> On Wed, Mar 2, 2022 at 2:57 AM Nathan Bossart <[email protected]> wrote:
>> I think there are a couple of advantages. For one, spinning is probably
>> not the best from a resource perspective.
>
> Just to be on the same page - by spinning do you mean - the async
> walsender waiting for the sync flushLSN in a for-loop with
> WaitLatch()?
Yes.
>> Also, this approach might fit in better
>> with the existing synchronous replication framework. When a WAL sender
>> realizes that it can't send up to the current "flush" LSN because it's not
>> synchronously replicated, it will request to be alerted when it is.
>
> I think you are referring to the way a backend calls SyncRepWaitForLSN
> and waits until any one of the walsender sets syncRepState to
> SYNC_REP_WAIT_COMPLETE in SyncRepWakeQueue. Firstly, SyncRepWaitForLSN
> blocking i.e. the backend spins/waits in for (;;) loop until its
> syncRepState becomes SYNC_REP_WAIT_COMPLETE. The backend doesn't do
> any other work but waits. So, spinning isn't avoided completely.
>
> Unless, I'm missing something, the existing syc repl queue
> (SyncRepQueue) mechanism doesn't avoid spinning in the requestors
> (backends) SyncRepWaitForLSN or in the walsenders SyncRepWakeQueue.
My point is that there are existing tools for alerting processes when an
LSN is synchronously replicated and for waking up WAL senders. What I am
proposing wouldn't involve spinning in XLogSendPhysical() waiting for
synchronous replication. Like SyncRepWaitForLSN(), we'd register our LSN
in the queue (SyncRepQueueInsert()), but we wouldn't sit in a separate loop
waiting to be woken. Instead, SyncRepWakeQueue() would eventually wake up
the WAL sender and trigger another iteration of WalSndLoop().
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
view thread (13+ messages) latest in thread
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], [email protected]
Subject: Re: Allow async standbys wait for sync replication
In-Reply-To: <20220304195602.GA1184024@nathanxps13>
* 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