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 | 24181.1465328284@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Parallel pg_dump's error reporting doesn't work worth squat (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Parallel pg_dump's error reporting doesn't work
worth squat
|
Список | 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 по дате отправления: