Hello Alexander,
On 2024-Apr-03, Alexander Korotkov wrote:
> Regarding the shmem data structure for LSN waiters. I didn't pick
> LWLock or ConditionVariable, because I needed the ability to wake up
> only those waiters whose LSN is already replayed. In my experience
> waking up a process is way slower than scanning a short flat array.
I agree, but I think that's unrelated to what I was saying, which is
just the patch I attach here.
> However, I agree that when the number of waiters is very high and flat
> array may become a problem. It seems that the pairing heap is not
> hard to use for shmem structures. The only memory allocation call in
> paritingheap.c is in pairingheap_allocate(). So, it's only needed to
> be able to initialize the pairing heap in-place, and it will be fine
> for shmem.
Ok.
With the code as it stands today, everything in WaitLSNState apart from
the pairing heap is accessed without any locking. I think this is at
least partly OK because each backend only accesses its own entry; but it
deserves a comment. Or maybe something more, because WaitLSNSetLatches
does modify the entry for other backends. (Admittedly, this could only
happens for backends that are already sleeping, and it only happens
with the lock acquired, so it's probably okay. But clearly it deserves
a comment.)
Don't we need to WaitLSNCleanup() during error recovery or something?
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"World domination is proceeding according to plan" (Andrew Morton)