Horton

Re: Latches vs lwlock contention

Peter Eisentraut <peter@eisentraut.org>

View thread View on postgr.es
From: Peter Eisentraut <peter@eisentraut.org>
To: Thomas Munro <thomas.munro@gmail.com>, vignesh C <vignesh21@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Yura Sokolov <y.sokolov@postgrespro.ru>, Andres Freund <andres@anarazel.de>
Date: 2023-07-06T09:58:09Z
Lists: pgsql-hackers 
On 04.03.23 20:50, Thomas Munro wrote:
> Subject: [PATCH v3 1/6] Allow palloc_extended(NO_OOM) in critical sections.
> 
> Commit 4a170ee9e0e banned palloc() and similar in critical sections, because an
> allocation failure would produce a panic.  Make an exception for allocation
> with NULL on failure, for code that has a backup plan.

I suppose this assumes that out of memory is the only possible error 
condition that we are concerned about for this?

For example, we sometimes see "invalid memory alloc request size" either 
because of corrupted data or because code does things we didn't expect. 
This would then possibly panic?  Also, the realloc code paths 
potentially do more work with possibly more error conditions, and/or 
they error out right away because it's not supported by the context type.

Maybe this is all ok, but it would be good to make the assumptions more 
explicit.

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