> > > > > That said, I have seen some folks post about writing a > > > perl or shell > > > > > script that runs every x minutes looking for connections > > > that have > > > > > been idle for > a certain amount of time and kill the backend > > > > > associated with it (sigterm, not -9...) > > > > > > > > what are the implications of killing a postmaster process? > > > > > > A Sigterm is generally considered safe. It's -9 and its ilk that > > > you need to be wary of. > > > > No it's not. See the archives. > > The only *safe* way to do it ATM is to restart the > database. SIGTERM > > may leave orphaned locks or such things in the system. > (Incidentally, > > -9 on a single backend should be safe I believe. The > postmaster will > > tell all concurrent connections to abort and restart. It's > not nice, > > but it should be safe - should perform onrmal recovery same > as if you > > pull the > > plug) > > Really? I was under the impression that doing a "kill > <backendpid>" on an idle connection would clean up those > things. Was that a discussion on hackers that brought this > up? And if so, what was the time period, I'd like to read through it. It's been brought up several times on hackers. Once back last autumn when looking at the pg_terminate_backend function, and it was brought up again this spring I think during one of the discussions about the instrumentation patch. I can't find the actual discussion at a quick look, but the quote from Tom on http://archives.postgresql.org/pgsql-hackers/2005-06/msg00970.php certainly shows there is a problem :-) The discussion should be somewhere around that timeframe (I think before it - before I came up with the idea to solve it that didn't work) //Magnus ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
