Re: Latches vs lwlock contention
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Maxim Orlov <orlovmg@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>,
Yura Sokolov <y.sokolov@postgrespro.ru>, Andres Freund <andres@anarazel.de>
Date: 2024-11-04T16:08:43Z
Lists: pgsql-hackers
On 10/09/2024 19:53, Maxim Orlov wrote: > I looked at the patch set and found it quite useful. > > The first 7 patches are just refactoring and may be committed separately > if needed. > There were minor problems: patch #5 don't want to apply clearly and the > #8 is complained > about partitionLock is unused if we build without asserts. So, I add a > PG_USED_FOR_ASSERTS_ONLY > to solve the last issue. > > Again, overall patch looks good and seems useful to me. Here is the > rebased v5 version based on Heikki's patch set above. Committed, thanks for the review! In case you're wondering, I committed some of the smaller patches separately, but also squashed some of them with the main patch, On closer look, the first patch, "Remove LOCK_PRINT() call that could point to garbage", wasn't fixing any existing issue. The LOCK_PRINT() was fine, because we held the partition lock. But it became necessary with the main patch, so I squashed it with that. And the others that I squashed were just not that interesting on their own. The rest of Thomas's SetLatches work remains, so I left the commitfest entry in "Needs review" state. -- Heikki Linnakangas Neon (https://neon.tech)
Commits
-
Fix crash if LockErrorCleanup() is called twice
- 51a0382e8d87 18.0 landed
-
Split ProcSleep function into JoinWaitQueue and ProcSleep
- 3c0fd64fec8e 18.0 landed
-
Move TRACE calls into WaitOnLock()
- 6ae0897e4241 18.0 landed
-
Set MyProc->heldLocks in ProcSleep
- 0464f25b6aa1 18.0 landed
-
Fix comment in LockReleaseAll() on when locallock->nLock can be zero
- 1fe0466cf2cb 18.0 landed
-
Allow a no-wait lock acquisition to succeed in more cases.
- 2346df6fc373 17.0 cited
-
Teach planner about more monotonic window functions
- 456fa635a909 16.0 cited