From: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
---|---|
To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Fix a race condition in ConditionVariableTimedSleep() |
Date: | 2025-05-05 16:21:29 |
Message-ID: | 96de6baf-d7db-47fe-9d2a-20fd93d07527@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
05.05.2025 17:05, Bertrand Drouvot пишет:
> Hi,
>
> On Mon, May 05, 2025 at 02:15:15PM +0300, Yura Sokolov wrote:
>> Interestingly, our colleague stepped into same problem recently [1] . It
>> happened because he attempted to make overcomplex timeout (SIGALARM) handler.
>>
>> But his solution was a bit different [2].
>>
>> [1] https://postgr.es/m/076eb7bd-52e6-4a51-ba00-c744d027b15c@postgrespro.ru
>> [2]
>> https://postgr.es/m/attachment/175030/0001-CV-correctly-handle-cv_sleep_target-change.patch
>>
>> And I believe, his solution is more elegant. Doesn't it?
>
> I'm not sure as it'd not maintain the initial intent to re-add to the
> wait list.
It will be re-added in next iteration of outer sleeping loop.
>> But in first step, I doubt there should be any thing that cancels condition
>> variable during WaitLatch.
>
> I'm not 100% sure.
There're no such things at the moment. WaitLatch doesn't check for
interrupts and doesn't do any other thing that could break
ConditionVariable. And I believe, if it start to do, we're going to be in
trouble.
> I "just" added an ereport(LOG,..) that has been enough to cancel the
condition
> variable and trigger the failed assertion.
It is because errfinish, called from ereport, invokes CHECK_FOR_INTERRUPTS.
Just wrap you ereport with HOLD_INTERRUPTS/RESUME_INTERRUPTS, and
everything will be "just" fine.
--
regards
Yura Sokolov aka funny-falcon
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2025-05-05 16:31:28 | Re: PG 18 release notes draft committed |
Previous Message | ADRIANO BOLLER | 2025-05-05 16:13:45 | Re: RFC: Command Restrictions by INI file with Audit Logging (DROP/TRUNCATE/DELETE) |