> > > > > 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
