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
