At Thu, 2 Jun 2016 12:17:11 -0400, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote in <20160602161711.GA239156@alvherre.pgsql> > Tom Lane wrote: > > Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes: > > > Apart from the invalid snapshot problem, I looked the patch > > > previously mentioned mainly for Windows. > > > > Thanks for looking! > > > > > Even though the threads started by beginthread cannot be > > > terminated cleanly from outside, but the whole process will soon > > > terminate anyway, so we could use TreminateThread. This seems > > > working. (Attached patch) > > > > Seems reasonable to me; I was unhappy about the lack of any direct > > equivalent to the child SIGTERMs that the Unix code does.
For sure, any of the "dangers" of TerminateThread don't matter for this case. https://msdn.microsoft.com/en-us/em-us/library/windows/desktop/ms686717(v=vs.85).aspx > If the target thread owns a critical section, the critical > section will not be released. > > If the target thread is allocating memory from the heap, the heap > lock will not be released. > > If the target thread is executing certain kernel32 calls when it > is terminated, the kernel32 state for the thread's process could > be inconsistent. > > If the target thread is manipulating the global state of a shared > DLL, the state of the DLL could be destroyed, affecting other > users of the DLL. > Given this testing, it's clear that the timeout on select() is useless; > we could get rid of it in vacuumdb.c too. I'll post a patch later. Agreed. Command pipes may be in blocking mode for the case. 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