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 24181.1465328284@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel pg_dump's error reporting doesn't work worth squat  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Parallel pg_dump's error reporting doesn't work worth squat  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <17504.1465225934@sss.pgh.pa.us>
>> Uh, what?  PQcancel is very carefully coded so that it's safe to use
>> in a signal handler.  If it's doing mallocs someplace, that would be
>> surprising.

> PQcancel is disigned to run in a signal handler on *Linux*, but
> the discussion here is that the equivalent of send/recv and the
> similars on Windows can be blocked by the TerminateThread'ed
> thread via heap lock.

What's your evidence for that?  I'd expect those to be kernel calls,
or whatever the equivalent concept is on Windows.  If they are not,
and in particular if they do malloc's, I think we have got problems
in many other contexts besides parallel dump.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Problem with dumping bloom extension
Next
From: Stephen Frost
Date:
Subject: Re: Problem with dumping bloom extension