Re: `pg_ctl init` crashes when run concurrently; semget(2) suspected
От | Thomas Munro |
---|---|
Тема | Re: `pg_ctl init` crashes when run concurrently; semget(2) suspected |
Дата | |
Msg-id | CA+hUKGK6DTMwq1_oN+J+PfRaSYHXBmY-kzmyU5dhDvCmMnnV5Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: `pg_ctl init` crashes when run concurrently; semget(2) suspected (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: `pg_ctl init` crashes when run concurrently; semget(2) suspected
|
Список | 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...
В списке pgsql-hackers по дате отправления: