Re: Parallel pg_dump's error reporting doesn't work worth squat - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parallel pg_dump's error reporting doesn't work worth squat
Date
Msg-id 29919.1464449541@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel pg_dump's error reporting doesn't work worth squat  (Amit Kapila <amit.kapila16@gmail.com>)
List 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 by date:

Previous
From: Kouhei Kaigai
Date:
Subject: Re: Does people favor to have matrix data type?
Next
From: Tom Lane
Date:
Subject: Re: Statement timeout