On 2021/03/02 10:10, Thomas Munro wrote:
> On Tue, Mar 2, 2021 at 12:00 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>> On Mon, Nov 16, 2020 at 8:56 PM Michael Paquier <michael@paquier.xyz> wrote:
>>> No objections with the two changes from pg_usleep() to WaitLatch() so
>>> they could be applied separately first.
>>
>> I thought about committing that first part, and got as far as
>> splitting the patch into two (see attached), but then I re-read
>> Fujii-san's message about the speed of promotion and realised that we
>> really should have something like a condition variable for walRcvState
>> changes. I'll look into that.
>
> Here's an experimental attempt at that, though I'm not sure if it's
> the right approach. Of course it's not necessary to use condition
> variables here: we could use recoveryWakeupLatch, because we're not in
> any doubt about who needs to be woken up. But then you could get
> constant wakeups while recovery is paused, unless you also suppressed
> that somehow. You could use the startup process's procLatch,
> advertised in shmem, but that's almost a condition variable. With a
> condition variable, you get to name it something like
> walRcvStateChanged, and then the programming rule is very clear: if
> you change walRcvState, you need to broadcast that fact (and you don't
> have to worry about who might be interested). One question I haven't
> got to the bottom of: is it a problem for the startup process that CVs
> use CHECK_FOR_INTERRUPTS()?
I found 0001 patch was committed in de829ddf23, and which added new
wait event WalrcvExit. This name seems not consistent with other wait
events. I'm thinking it's better to rename it to WalReceiverExit. Thought?
Patch attached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
