Re: Missed check for too-many-children in bgworker spawning

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Missed check for too-many-children in bgworker spawning
Дата
Msg-id 7678.1570478628@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Missed check for too-many-children in bgworker spawning  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Missed check for too-many-children in bgworker spawning  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Oct 6, 2019 at 1:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The attached proposed patch fixes this by making bgworker spawning
>> include a canAcceptConnections() test.

> I think it used to work this way -- not sure if it was ever committed
> this way, but it at least did during development -- and we ripped it
> out because somebody (Magnus?) pointed out that if you got close to
> the connection limit, you could see parallel queries start failing,
> and that would suck. Falling back to non-parallel seems more OK in
> that situation than actually failing.

I'm not following your point?  Whatever you might think the appropriate
response is, I'm pretty sure "elog(FATAL) out of the postmaster" is not
it.  Moreover, we have to --- and already do, I trust --- deal with
other resource-exhaustion errors in exactly the same code path, notably
fork(2) failure which we simply can't predict or prevent.  Doesn't the
parallel query logic already deal sanely with failure to obtain as many
workers as it wanted?

            regards, tom lane



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Transparent Data Encryption (TDE) and encrypted files
Следующее
От: Andres Freund
Дата:
Сообщение: Re: expressive test macros (was: Report test_atomic_ops() failuresconsistently, via macros)