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

At Tue, 07 Jun 2016 15:38:04 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <24181(dot)1465328284(at)sss(dot)pgh(dot)pa(dot)us>
> 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.

Well, I found that I misunderstood your following sentence.

> Your original suggestion to use write_msg would end up going
> through fprintf, which might well use malloc internally. (It's
> possible that Windows' version of write() could too, I suppose,
> but that's probably as low-level as we are going to get.)

I took the sentence enclosed by parentheses as that write() or
other syscalls may blocked by heap-lock on Windows. But it should
mean that "We have no way than to regard Windows' version of
write() as a kernel call, that is, heap-lock safe". It seems
quite natural and I totally agree to the judgment.

Consequently, I agree to just use write(), not write_msg() and
consider the combination of PQcancel and TerminateThread safe on
Windows.

Sorry for my confusion.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center