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
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 |