| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | "Burd, Greg" <greg(at)burd(dot)me> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gavin Panella <gavinpanella(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: `pg_ctl init` crashes when run concurrently; semget(2) suspected |
| Date: | 2025-08-16 03:04:47 |
| Message-ID: | CA+hUKGK6DTMwq1_oN+J+PfRaSYHXBmY-kzmyU5dhDvCmMnnV5Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Aug 16, 2025 at 2:25 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-08-16 03:16:30 | Re: `pg_ctl init` crashes when run concurrently; semget(2) suspected |
| Previous Message | Thomas Munro | 2025-08-16 02:25:59 | Re: `pg_ctl init` crashes when run concurrently; semget(2) suspected |