At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in <17504.1465225...@sss.pgh.pa.us> > 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.
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. > > 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. Yeah, it's ugly. But if we assume write() can be blocked, the similar system calls used within PQcancel can be blocked, too. If we don't assume so, using write instead of write_msg would do. The problem I think is we don't have (or they don't offer?) enough knowlegde about the inside of Windows APIs. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
