Re: Minimal logical decoding on standbys - Mailing list pgsql-hackers

From Drouvot, Bertrand
Subject Re: Minimal logical decoding on standbys
Date
Msg-id be47b1d1-e3c9-a269-e597-a25726c64a3d@gmail.com
Whole thread Raw
In response to Re: Minimal logical decoding on standbys  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Minimal logical decoding on standbys  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Hi,

On 3/31/23 1:58 PM, Amit Kapila wrote:
> On Fri, Mar 31, 2023 at 4:17 PM Drouvot, Bertrand
> <bertranddrouvot.pg@gmail.com> wrote:
>>
> 
> + * This is needed for logical decoding on standby. Indeed the "problem" is that
> + * WalSndWaitForWal() waits for the *replay* LSN to increase, but gets woken up
> + * by walreceiver when new WAL has been flushed. Which means that typically
> + * walsenders will get woken up at the same time that the startup process
> + * will be - which means that by the time the logical walsender checks
> + * GetXLogReplayRecPtr() it's unlikely that the startup process
> already replayed
> + * the record and updated XLogCtl->lastReplayedEndRecPtr.
> + *
> + * The ConditionVariable XLogRecoveryCtl->replayedCV solves this corner case.
> 
> IIUC we are introducing condition variables as we can't rely on
> current wait events because they will lead to spurious wakeups for
> logical walsenders due to the below code in walreceiver:
> XLogWalRcvFlush()
> {
> ...
> /* Signal the startup process and walsender that new WAL has arrived */
> WakeupRecovery();
> if (AllowCascadeReplication())
> WalSndWakeup();
> 
> Is my understanding correct?
> 

Both the walsender and the startup process are waked up at the
same time. If the walsender does not find any new record that has been replayed
(because the startup process did not replay yet), then it will sleep during i
ts timeout time (then delaying the decoding).

The CV helps to wake up the walsender has soon as a replay is done.

> Can't we simply avoid waking up logical walsenders at this place and
> rather wake them up at ApplyWalRecord() where the 0005 patch does
> conditionvariable broadcast? Now, there doesn't seem to be anything
> that distinguishes between logical and physical walsender but I guess
> we can add a variable in WalSnd structure to identify it.
> 

That sounds like a good idea. We could imagine creating a LogicalWalSndWakeup()
doing the Walsender(s) triage based on a new variable (as you suggest).

But, it looks to me that we:

- would need to go through the list of all the walsenders to do the triage
- could wake up some logical walsender(s) unnecessary

This extra work would occur during each replay.

while with the CV, only the ones in the CV wait queue would be waked up.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Reid Thompson
Date:
Subject: Re: FW: Add the ability to limit the amount of memory that can be allocated to backends.
Next
From: Melanie Plageman
Date:
Subject: Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode