Re: `pg_ctl init` crashes when run concurrently; semget(2) suspected

On Wed, Aug 13, 2025 at 8:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> In the meantime, though, we'll have to deal with the existing
> behavior for years to come.  So I'll go ahead with that patch.
> I like having a loop limit there anyway --- I was never exactly
> convinced that retrying indefinitely was a good idea.

LGTM.  1000 does seem like "enough" following the arguments made
earlier.  Gavin does also raise a good point that it might be nice to
randomise the search a bit but that sounds like another patch for
master.

It's not a very nice interface and I hope to get rid of it one day.
When I'm working on a Mac I frequently finish up with leaked SysV IPC
entries of both kinds and have to clean them up manually, though
admittedly while hacking and debugging PostgreSQL you exit in weird
and wonderful ways.

FWIW in early prototype multithreading patches you can just use
sem_init() on all these systems since you don't need pshared=1.  It
works, but macOS spews "deprecated" warnings when you compile.  Kinda
weird for the best semaphore API IMHO.  But you can also just
implement LWLock on top of pthread_rwlock_t or futexes with some more
work, so I'm not bothered about that and there are more important
problems to solve in that project for now...

Here's a story from an Apple engineer about why they don't have pshared=1:

https://www.quora.com/Why-does-OS-X-not-support-unnamed-semaphores

I don't actually see any reason they couldn't adopt the same trick as
other modern systems, without an ABI break: use the *address* to
identify semaphores, converted to {VM object, offset} to form the key
in a hash table of waitlists that only has an entry while someone is
actually waiting.  No expensive kernel resources while not being
waited on, no leaky SysV namespace management, ideal access control by
memory map.  But you probably have to move to California if you want
to fix that.

They also have the CMU Mach semaphore API, semaphore_create(), which
some other projects seem to be using.  I think it could be made to
work, but Mach ports are not inherited by child processes so you'd
have to send them explicitly after fork() which sounds painful and
slow, not to mention that the documentation for all that is thin on
the ground...