Re: Parallel pg_dump's error reporting doesn't work worth squat

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Parallel pg_dump's error reporting doesn't work worth squat
Дата
Msg-id 29919.1464449541@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Parallel pg_dump's error reporting doesn't work worth squat  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> On Sat, May 28, 2016 at 5:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It looks like the vacuumdb.c version of this code actually is tied
>> into an interrupt handler, but whoever copied it for parallel.c just
>> ripped out the CancelRequested checks, making the looping behavior
>> pretty useless.

> It seems to me that CancelRequested checks were introduced in vacuumdb.c as
> part of commit a1792320 and select_loop for parallel.c version exists from
> commit 9e257a18 which got committed earlier.

Huh, interesting.  I wonder how parallel.c's select_loop got to be like
that then?  The git history offers no clue: it is essentially the same as
HEAD as far back as the initial commit of parallel.c.  It certainly looks
like someone intended to introduce a cancel check and never did, or had
one and took it out without simplifying the rest of the logic.

Anyway, AFAICS the time limit on select() wait is completely useless in
the code as it stands; but we'll likely want to add a cancel check there,
so ripping it out wouldn't be a good plan.  I'll change the added comment.
        regards, tom lane



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

Предыдущее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Does people favor to have matrix data type?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Statement timeout