Re: Latches vs lwlock contention

On Tue, 1 Nov 2022 at 16:40, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Fri, Oct 28, 2022 at 4:56 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > See attached sketch patches. I guess the main thing that may not be
> > good enough is the use of a fixed sized latch buffer. Memory
> > allocation in don't-throw-here environments like the guts of lock code
> > might be an issue, which is why it just gives up and flushes when
> > full; maybe it should try to allocate and fall back to flushing only
> > if that fails.
>
> Here's an attempt at that. There aren't actually any cases of uses of
> this stuff in critical sections here, so perhaps I shouldn't bother
> with that part. The part I'd most like some feedback on is the
> heavyweight lock bits. I'll add this to the commitfest.

The patch does not apply on top of HEAD as in [1], please post a rebased patch:

=== Applying patches on top of PostgreSQL commit ID
456fa635a909ee36f73ca84d340521bd730f265f ===
=== applying patch ./v2-0003-Use-SetLatches-for-condition-variables.patch
patching file src/backend/storage/lmgr/condition_variable.c
patching file src/backend/storage/lmgr/lwlock.c
Hunk #1 FAILED at 183.
1 out of 1 hunk FAILED -- saving rejects to file
src/backend/storage/lmgr/lwlock.c.rej
patching file src/include/storage/condition_variable.h
patching file src/include/storage/lwlock.h
Hunk #1 FAILED at 193.
1 out of 1 hunk FAILED -- saving rejects to file
src/include/storage/lwlock.h.rej

[1] - http://cfbot.cputube.org/patch_41_3998.log

Regards,
Vignesh