Re: Get rid of WALBufMappingLock - Mailing list pgsql-hackers

From Yura Sokolov
Subject Re: Get rid of WALBufMappingLock
Date
Msg-id 54d99494-5af1-4f21-95a6-fa22292d72dc@postgrespro.ru
Whole thread Raw
In response to Re: Get rid of WALBufMappingLock  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
26.02.2025 11:52, Andrey Borodin wrote:
>> On 25 Feb 2025, at 20:19, Alexander Korotkov <aekorotkov@gmail.com> wrote:
>>
>>
> 
> 
> Hi!
> 
> One little piece of code looks suspicious to me. But I was not raising concern because I see similar code everywhere
inthe codebase. But know Kirill asked to me explain what is going on and I cannot.
 
> 
> This seems to be relevant… so.
> 
> +    while (upto >= pg_atomic_read_u64(&XLogCtl->InitializedUpTo))
>    // Assume ConditionVariableBroadcast() happened here, but before next line
> +        ConditionVariableSleep(&XLogCtl->InitializedUpToCondVar, WAIT_EVENT_WAL_BUFFER_INIT);
> +    ConditionVariableCancelSleep();
> 
> Won’t this sleep wait forever?

Because ConditionVariableSleep doesn't sleep for the first time.
It just performs ConditionVariablePrepareToSleep and immediately returns.
So actual condition of `while` loop is checked at least twice before going
to sleep.

> 
> I see about 20 other occurrences of similar code, so, perhaps, everything is fine. But I would greatly appreciate a
littlepointers on why it works.
 

-------
regards
Yura Sokolov aka funny-falcon



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: Improve CRC32C performance on SSE4.2
Next
From: Michael Paquier
Date:
Subject: Re: per backend WAL statistics