Re: Reducing sema usage (was Postmaster dies with many child processes)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reducing sema usage (was Postmaster dies with many child processes)
Дата
Msg-id 5837.917743345@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Reducing sema usage (was Postmaster dies with many child processes)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Re: Reducing sema usage (was Postmaster dies with many child processes)  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
I said:
> Any thoughts about which way to jump?  I'm sort of inclined to take
> the simpler approach myself...

A further thought: we could leave the semaphore management as-is,
and instead try to make running out of semaphores a less catastrophic
failure.  I'm thinking that the postmaster could be the one to try
to allocate more semaphores whenever there are none left, just before
trying to fork a new backend.  (The postmaster has access to the same
shared memory as the backends, right?  So no reason it couldn't do this.)
If the allocation fails, it can simply refuse the connection request,
rather than having to proceed as though we'd had a full-fledged backend
crash.  This only works because we can predict the number of semas
needed by an additional backend -- but we can: one.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Reducing sema usage (was Postmaster dies with many child processes)
Следующее
От: "Cary O'Brien"
Дата:
Сообщение: Backends and semaphores