Horton

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

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: "Burd, Greg" <greg@burd.me>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Gavin Panella <gavinpanella@gmail.com>, pgsql-hackers@postgresql.org
Date: 2025-08-16T03:04:47Z
Lists: pgsql-hackers 
On Sat, Aug 16, 2025 at 2:25 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Supposing posix_sema.c checked that the maximum number of backends
> didn't exceed SEM_VALUE_MAX and refused to start up if so (I suppose
> today if you later exceed it in sem_post() you'll get either FATAL:
> EOVERFLOW on POSIX 2024 systems or unspecified behaviour, likely
> including a hang due to a corrupted counter, I guess).

And just by the way, each backend has its own semaphore, so in actual
usage we're probably only talking about the "superfluous wakeups"
mentioned in lwlock.c, clog.c and procarray.c.  I suppose it's not
expected to go very high at all?  I was just trying to think about
where the bounds on that come from in theory, while working through
the case for ignoring EOVERFLOW...

Commits

  1. Don't treat EINVAL from semget() as a hard failure.

  2. Give up on running with NetBSD/OpenBSD's default semaphore settings.