Horton

Re: Latches vs lwlock contention

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Yura Sokolov <y.sokolov@postgrespro.ru>, Andres Freund <andres@anarazel.de>
Date: 2022-11-01T11:09:25Z
Lists: pgsql-hackers

Attachments

On Fri, Oct 28, 2022 at 4:56 PM Thomas Munro <thomas.munro@gmail.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.

Commits

  1. Fix crash if LockErrorCleanup() is called twice

  2. Split ProcSleep function into JoinWaitQueue and ProcSleep

  3. Move TRACE calls into WaitOnLock()

  4. Set MyProc->heldLocks in ProcSleep

  5. Fix comment in LockReleaseAll() on when locallock->nLock can be zero

  6. Allow a no-wait lock acquisition to succeed in more cases.

  7. Teach planner about more monotonic window functions