Re: Fix a race condition in ConditionVariableTimedSleep()
От | Bertrand Drouvot |
---|---|
Тема | Re: Fix a race condition in ConditionVariableTimedSleep() |
Дата | |
Msg-id | aBjFnZxujx22edMx@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
Ответ на | Re: Fix a race condition in ConditionVariableTimedSleep() (Yura Sokolov <y.sokolov@postgrespro.ru>) |
Ответы |
Re: Fix a race condition in ConditionVariableTimedSleep()
|
Список | pgsql-hackers |
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. > But in first step, I doubt there should be any thing that cancels condition > variable during WaitLatch. I'm not 100% sure. > Most probably you did wrong thing. I "just" added an ereport(LOG,..) that has been enough to cancel the condition variable and trigger the failed assertion. I agree that you could still consider this as wrong thing if you think that we should not do anything that cancels condition variable during WaitLatch though. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: