Let's drop support for named POSIX semaphores

Hi Tom,

+1. Looks like the only platform that picked it by default was a very old
mac.

Two nits:

IPCProtection in posix_sema.c is now unused,
clang -Wunused-macros points at it. The fcntl.h and sys/stat.h
includes were only there for sem_open() and stat(), so they can go
too.

Also, runtime.sgml still says "POSIX semaphores are used on Linux and
FreeBSD while other platforms use System V."

Thanks,
Shihao

On 26/10/2026 04:20, Tom Lane wrote:

So I think it's time to just drop it, as per attached. Thoughts?

+1

- Heikki

On 26.10.26 03:20, Tom Lane wrote:

After fixing a niggling compiler warning (6e06f6281) I started to
wonder why don't we just drop support for named POSIX semaphores.
We originally put that code in for the benefit of macOS, but SysV
semaphores have been the preferred alternative on that platform since
2002,

There were some recent discussions about removing the requirement of
SysV IPC to allow macOS sandboxing mechanisms to be used. These
discussions mainly focus on SysV shared memory, which is currently a
hard requirement, but I would expect that switching to non-SysV
semaphores would be part of such an undertaking. So I think adding
another hard requirement on SysV IPC would not be preferable.

Peter Eisentraut <peter@eisentraut.org> writes:

There were some recent discussions about removing the requirement of
SysV IPC to allow macOS sandboxing mechanisms to be used. These
discussions mainly focus on SysV shared memory, which is currently a
hard requirement, but I would expect that switching to non-SysV
semaphores would be part of such an undertaking. So I think adding
another hard requirement on SysV IPC would not be preferable.

Named POSIX semaphores are not a credible replacement for SysV
semaphores, because of their performance issues (which are just
as real on macOS as anywhere else). So I think the direction we'd
have to go in to make that happen is to replace all the semaphore
stuff with futexes or some other low-level primitive, as Munro
speculated about in one of the threads I cited.

regards, tom lane

+1 on dropping it.

Peter, as to your concern that this adds another hard SysV dependency
and so cuts against the work to let PostgreSQL run without SysV IPC (for
macOS sandboxing): I don't think removing *named* POSIX semaphores costs
that effort anything, because named POSIX semaphores are not the thing
that effort would reach for.

The non-SysV semaphore path we'd actually want is the *unnamed* kind
(sem_init), which posix_sema.c already prefers and which backs the sem_t
structs out of shared memory. The named kind (sem_open) is only the
fallback, and the header comment there spells out why it's a dead end
for this:

With unnamed semaphores, the sem_t structs live in an array in shared
memory [...] Therefore, the named-semaphore code *does not cope with
EXEC_BACKEND*.

So a SysV-free future built on POSIX semaphores runs through the unnamed
path Tom is keeping, not the named path he's removing. Dropping named
POSIX semaphores narrows the matrix to "SysV or unnamed-POSIX".

(+1 as well to Shihao's two nits, the now-unused IPCProtection macro
and the stale runtime.sgml line about which platforms use which.)

best,

-greg

Greg Burd <greg@burd.me> writes:

Peter, as to your concern that this adds another hard SysV dependency
and so cuts against the work to let PostgreSQL run without SysV IPC (for
macOS sandboxing): I don't think removing *named* POSIX semaphores costs
that effort anything, because named POSIX semaphores are not the thing
that effort would reach for.

The non-SysV semaphore path we'd actually want is the *unnamed* kind
(sem_init), which posix_sema.c already prefers and which backs the sem_t
structs out of shared memory.

... and which macOS still doesn't support :-(. But moving from SysV
to named POSIX semaphores isn't realistic performance-wise, so we need
some other path altogether if we hope to address the sandboxing
problem.

(+1 as well to Shihao's two nits, the now-unused IPCProtection macro
and the stale runtime.sgml line about which platforms use which.)

Yeah, I noticed a few comments that need updates as well.

regards, tom lane

Hi,

On 2026-10-26 11:42:56 -0400, Tom Lane wrote:

So I think the direction we'd have to go in to make that happen is to
replace all the semaphore stuff with futexes or some other low-level
primitive, as Munro speculated about in one of the threads I cited.

Agreed, that's the right direction. We really aren't using semaphores in a way
that benefits from them being semaphores. In fact, we have to fix up the
semaphore counters in a bunch of places that would not need such complication
with a better primitive.

FWIW, I recalled Thomas posting patches for macos futexes before. I didn't
immediately find them, but did quickly find the branch that implements futexes
on macos:

https://github.com/macdice/postgres/commits/pg_futex/
https://github.com/macdice/postgres/commit/bf2ceb73fe8a48ece981a82ef103284e5dfc0a54

Given that, as Thomas notes in [1]/messages/by-id/CA+hUKGKAPR=NXxMTCmEomCUpq+mrPLDVyfVa4bKZqfDjwyzD7Q@mail.gmail.com, macos finally documents the futex APIs,
that seems like the obvious way forward.

I also found an older branch of Thomas' that abstracts futexes across a number
of platforms [2]https://github.com/macdice/postgres/commits/pg_futex/ and then implements semaphores on top of those futexes.

It's *really* annoying that window's WaitOnAddress() equivalent explicitly
requires the waiter and waker to be threads in the same process :(.

E.g. lwlocks would be faster *and* the code would be simpler if futexes could
be used everywhere.

Greetings,

Andres

[1]: /messages/by-id/CA+hUKGKAPR=NXxMTCmEomCUpq+mrPLDVyfVa4bKZqfDjwyzD7Q@mail.gmail.com
[2]: https://github.com/macdice/postgres/commits/pg_futex/

Andres Freund <andres@anarazel.de> writes:

It's *really* annoying that window's WaitOnAddress() equivalent explicitly
requires the waiter and waker to be threads in the same process :(.
E.g. lwlocks would be faster *and* the code would be simpler if futexes could
be used everywhere.

Well, in our hypothetical multithreaded future, that might be fine.
I'm wondering how much change we should try to make in this area now,
rather than after (or as part of) the multithreading work.

regards, tom lane

On Monday, October 26th, 2026 at 1:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andres Freund <andres@anarazel.de> writes:

It's *really* annoying that window's WaitOnAddress() equivalent explicitly
requires the waiter and waker to be threads in the same process :(.
E.g. lwlocks would be faster *and* the code would be simpler if futexes could
be used everywhere.

Well, in our hypothetical multithreaded future, that might be fine.
I'm wondering how much change we should try to make in this area now,
rather than after (or as part of) the multithreading work.

regards, tom lane

I don't think Windows has to block this, and I don't think the API
would need to change when threads arrive.

Kernel futexes that work across processes exist on Linux, FreeBSD,
OpenBSD and NetBSD (both key shared waits on the backing VM object,
not the VA), DragonFly, and macOS 14.4+ via os_sync_wait_on_address()
with the SHARED flags, which is what Thomas's pg_futex branch uses
[0]: https://github.com/macdice/postgres/commit/bf2ceb73fe8a48ece981a82ef103284e5dfc0a54
macOS needing a fallback in any case, so the question is what the
fallback looks like rather than whether we need one.

Thomas's pg_futex.h already wraps the value in a struct to leave room
for one. The fallback I'd suggest is to embed a spinlock and a
proclist_head in that struct, and have waiters sleep on their own
PGPROC semaphore: enqueue, recheck the value, release, sleep; the
waker updates the value, dequeues, and posts. That is the same thing
lwlock.c and condition_variable.c already do by hand, done once.
Embedding the queue rather than using a parking lot hashed by address
matters because DSM segments map at different addresses in different
backends; the native kernels don't care, but a userspace hash would.

With that, LWLocks and CVs could be written once against pg_futex,
getting native futexes where the kernel has them and today's
behavior elsewhere, and the semaphore count fixups Andres mentioned
move into one place. In a multithreaded build Windows simply moves
to the native tier via WaitOnAddress(), and the generic fallback can
sit on pg_threads.h mtx/cnd the way Zig's std.Thread.Futex does [1]https://github.com/ziglang/zig/blob/master/lib/std/Thread/Futex.zig.

I'd keep the API to 32-bit wait(expected, timeout), wake_one() and
wake_all(), since macOS and Windows can't wake an arbitrary count and
Linux and FreeBSD only wait on 32-bit words. Latches are out of scope:
a futex can't multiplex with sockets or postmaster death.

The open question for me is performance. Haris's futex-based
LWLockWaitListLock() patch [2]/messages/by-id/DM6PR18MB29081469262A7BBCE85220B3A8112@DM6PR18MB2908.namprd18.prod.outlook.com was a large win on Neoverse V3 but a
small loss on recent x86, so a futex LWLock needs real numbers, not
assumptions.

If there is any agreement on this approach I'd be happy to picked up
the lwlock-futex branch [3]https://github.com/macdice/postgres/commits/lwlock-futex/ and try the embedded-queue fallback on
top of it.

thoughts?

-greg

[0]: https://github.com/macdice/postgres/commit/bf2ceb73fe8a48ece981a82ef103284e5dfc0a54
[1]: https://github.com/ziglang/zig/blob/master/lib/std/Thread/Futex.zig
[2]: /messages/by-id/DM6PR18MB29081469262A7BBCE85220B3A8112@DM6PR18MB2908.namprd18.prod.outlook.com
[3]: https://github.com/macdice/postgres/commits/lwlock-futex/