Date: Fri, 4 Mar 2022 11:56:02 -0800
From: Nathan Bossart <nathandbossart@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Allow async standbys wait for sync replication
Message-ID: <20220304195602.GA1184024@nathanxps13>
References: <20220228185732.GB944837@nathanxps13>
 <CALj2ACVNxtGatZKaZm12z8YpUkUW7zewALZJu0iuhGV9Q1ygjA@mail.gmail.com>
 <20220301060528.GA1026683@nathanxps13>
 <20220301.163431.1826638724406024793.horikyota.ntt@gmail.com>
 <20220301170537.GA1031413@nathanxps13>
 <CALj2ACUdNd=vVTOdz=UMuWxTVJgzsCUhOwJ6mMsXK150Ec-QOQ@mail.gmail.com>
 <20220301212700.GB1033258@nathanxps13>
 <CALj2ACULc_2TbC44fdFbpPCJ-AmvixdLY9z=LgMfz07QXx9-bg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALj2ACULc_2TbC44fdFbpPCJ-AmvixdLY9z=LgMfz07QXx9-bg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20220304195602.GA1184024%40nathanxps13>
Precedence: bulk

On Wed, Mar 02, 2022 at 09:47:09AM +0530, Bharath Rupireddy wrote:
> On Wed, Mar 2, 2022 at 2:57 AM Nathan Bossart <nathandbossart@gmail.com> 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