At Tue, 07 Jun 2016 15:38:04 -0400, Tom Lane <> wrote in 
> Kyotaro HORIGUCHI <> writes:
> > At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane <> wrote in 
> > <>
> >> 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

Sorry for my confusion.


Kyotaro Horiguchi
NTT Open Source Software Center

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to