On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote: > On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote: > > Andres Freund <and...@anarazel.de> writes: > > > On Tuesday 29 December 2009 16:22:54 Tom Lane wrote: > > >> This seems like a fairly bad idea. One of the intended use-cases is > > >> to be able to manually "kill -INT" a misbehaving backend. Assuming > > >> that there will be valid info about the signal in shared memory will > > >> break that. > > > > > > Well. That already is the case now. MyProc->recoveryConflictMode is > > > checked to recognize what kind of conflict is being resolved... > > > > In that case, HS has already broken it, and we need to fix it not make > > it worse. > > > > My humble opinion is that SIGINT should not be overloaded with multiple > > meanings. We already have a multiplexed signal mechanism, which is what > > should be used for any additional signal reasons HS may need to > > introduce. > > It's a revelation to me, but yes, I see it now and agree. > > I'm looking at Fujii-san's multiplexing patch from Jul 31 to rewrite > this code using that mechanism. It sounds like it's a neat fit and it > should get around the bug report from Kris also if it all works. Hm. I just read a bit of that multiplexing facility (out of a different reason) and I have some doubt about it being used unmodified for canceling backends:
procsignal.c: /* * Note: Since there's no locking, it's possible that the target * process detaches from shared memory and exits right after this * test, before we set the flag and send signal. And the signal slot * might even be recycled by a new process, so it's remotely possible * that we set a flag for a wrong process. That's OK, all the signals * are such that no harm is done if they're mistakenly fired. */ procsignal.h: ... * Also, because of race conditions, it's important that all the signals be * defined so that no harm is done if a process mistakenly receives one. */ When cancelling a backend that behaviour could be a bit annoying ;-) I guess locking procarray during sending the signal should be enough? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
