Re: Get rid of WALBufMappingLock
Yura Sokolov <y.sokolov@postgrespro.ru>
From: Yura Sokolov <y.sokolov@postgrespro.ru>
To: Andrey Borodin <x4mmm@yandex-team.ru>,
Alexander Korotkov <aekorotkov@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>,
Pavel Borisov <pashkin.elfe@gmail.com>, Victor Yegorov <vyegorov@gmail.com>,
"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
Andres Freund <andres@anarazel.de>, Kirill Reshke <reshke@yandex-team.ru>
Date: 2025-02-28T12:12:36Z
Lists: 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 in the 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 little pointers on why it works. ------- regards Yura Sokolov aka funny-falcon