Re: [HACKERS] parallel.c oblivion of worker-startup failures

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] parallel.c oblivion of worker-startup failures
Дата
Msg-id 22410.1512572062@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] parallel.c oblivion of worker-startup failures  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] parallel.c oblivion of worker-startup failures
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I'm not in love with that part of the fix; the other parts of that if
> statement are just testing variables, and a function call that takes
> and releases an LWLock is a lot more expensive.  Furthermore, that
> test will often be hit in practice, because we'll often arrive at this
> function before workers have actually finished.  On top of that, we'll
> typically arrive here having already communicated with the worker in
> some way, such as by receiving tuples, which means that in most cases
> we already know that the worker was alive at least at some point, and
> therefore the extra test isn't necessary.  We only need that test, if
> I understand correctly, to cover the failure-to-launch case, which is
> presumably very rare.

Maybe track "worker is known to have launched" in the leader's state
someplace?

            regards, tom lane


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Transaction control in procedures
Следующее
От: Ildus Kurbangaliev
Дата:
Сообщение: Re: [HACKERS] Custom compression methods