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 по дате отправления: