Re: Regression tests fail on OpenBSD due to low semmns value
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-12-17T03:11:37Z
Lists: pgsql-hackers
Attachments
- 0001-A-basic-API-for-futexes.patch (application/x-patch) patch 0001
- 0002-Add-futex-based-semaphore-replacement.patch (application/x-patch) patch 0002
- 0003-Use-futex-based-semaphores-on-macOS.patch (application/x-patch) patch 0003
On Mon, Dec 16, 2024 at 6:00 PM Alexander Lakhin <exclusion@gmail.com> wrote: > It turned out that OpenBSD has semmns as low as 60 (see [4]) Whenever I run into this, or my Mac requires manual ipcrm to clean up leaked SysV kernel junk, I rebase my patch for sema_kind = 'futex'. Here it goes. It could be updated to support NetBSD I believe, but I didn't try as its futex stuff came out later. Then I remember why I didn't go anywhere with it. It triggers a thought loop about flipping it all around: use futexes to implement lwlocks directly in place, and get rid of semaphores completely, but that involves a few rabbit holes and sub-projects. From memory: classic r/w lock implementation on futexes is tricky but doable in the portability constraints, futex fallback implementation even works surprisingly well but has fun memory map sub-problems, actually lwlock is not really a classic r/w lock as it has sprouted extra funky APIs that lead the intrepid rabbit-holer to design an entirely different new concurrency primitive that is really wanted for those users, a couple of other places use raw semaphores directly namely procarray.c and clog.c and if you stare at those for long you will be overwhelmed with a desire to rewrite them, EOVERFLOW.
Commits
-
Try to avoid semaphore-related test failures on NetBSD/OpenBSD.
- a46311ed7214 17.3 landed
- 38da053463be 18.0 landed