Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes:
> At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in
> <11515.1464961...@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
