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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: alvherre(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parallel pg_dump's error reporting doesn't work worth squat
Date: 2016-06-07 19:38:04
Message-ID: 24181.1465328284@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <17504(dot)1465225934(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2016-06-07 20:38:46 Re: Problem with dumping bloom extension
Previous Message Robert Haas 2016-06-07 19:23:46 Re: Problem with dumping bloom extension