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

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <11515(dot)1464961470(at)sss(dot)pgh(dot)pa(dot)us>
>> I think that this one:
>>> If the target thread is allocating memory from the heap, the heap
>>> lock will not be released.
>> is potentially a hazard, which is why I made sure to use write_stderr
>> later on in the console interrupt handler. 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 have to admit that I forgot about the possible malloc's, and
> PQcancel() can be blocked from the same reason.

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.

> If the issue to be settled here is the unwanted error messages,
> we could set a flag to instruct write_msg to sit silent. Anyway
> the workers should have been dead that time so discarding any
> error messages don't matter.
> What do you think about this?

This is really ugly and I'm unconvinced that it fixes anything.
write_msg is hardly the only place in a worker thread that might
be doing malloc's; moreover, preventing workers from entering it
after we start a shutdown does nothing for workers that might be
in it already.

regards, tom lane