Hi, On 2024-09-02 13:03:07 +0300, Heikki Linnakangas wrote: > On 01/09/2024 09:27, Andres Freund wrote: > > In the next few days I'll add a bunch more documentation and comments as > > well > > as some better perf numbers (assuming my workstation survived...). > > Yeah, a high-level README would be nice. Without that, it's hard to follow > what "handed out" and "defined" above means for example.
Yea - I had actually written a bunch of that before, but then redesigns just obsoleted most of it :( FWIW, "handed out" is an IO handle acquired by code, which doesn't yet have an operation associated with it. Once "defined" it actually could be - but isn't yet - executed. > A few quick comments the patches: > > v2.0-0001-bufmgr-Return-early-in-ScheduleBufferTagForWrit.patch > > +1, this seems ready to be committed right away. Cool > v2.0-0002-Allow-lwlocks-to-be-unowned.patch > > With LOCK_DEBUG, LWLock->owner will point to the backend that acquired the > lock, but it doesn't own it anymore. That's reasonable, but maybe add a > boolean to the LWLock to mark whether the lock is currently owned or not. Hm, not sure it's worth doing that... > The LWLockReleaseOwnership() name is a bit confusing together with > LWLockReleaseUnowned() and LWLockrelease(). From the names, you might think > that they all release the lock, but LWLockReleaseOwnership() just > disassociates it from the current process. Rename it to LWLockDisown() > perhaps. Yea, that makes sense. > v2.0-0008-aio-Skeleton-IO-worker-infrastructure.patch > > My refactoring around postmaster.c child process handling will conflict with > this [1]. Not in any fundamental way, but can I ask you to review those > patch, please? After those patches, AIO workers should also have PMChild > slots (formerly known as Backend structs). I'll try to do that soonish! Greetings, Andres Freund
