On Thursday 12 May 2005 10:24, Tom Lane wrote:
> Andrew - Supernews <andrew+nonews@supernews.com> writes:
> > What currently happens is that backends respond to kill -15 (_NOT_ -9)
> > by cleaning up and exiting. This code path is used for implementing the
> > stop -mfast option, which means that as it currently exists, the cleanup
> > only has to be good enough to let other backends get out of critical
> > sections and complete their own rollback-and-exit safely.
>
> Exactly. In theory it probably works fine to allow one backend to exit
> via kill -TERM, but it cannot be claimed that that behavior has been
> tested to any significant extent --- "fast" shutdown is not stressing it
> in the same way.
>
> I think this is largely a question of someone doing a significant amount
> of stress testing: gun live server processes with "kill -TERM" in an
> active system, and keep an eye out for resource leaks, held locks, and
> so on. It would be more convincing if the processes getting zapped are
> executing a wide variety of SQL, too --- I'd not feel very confident
> given only tests of killing, say, pgbench threads.
>
Cause I know you wont be satisfied with anecdotal evidence, I thought I would
just say that I have done kill's on specific backends in a high load OLTP
process, with 1000+ active connections, for years and not had a problem with
it yet.
Not that I wouldn't like to see some specific, thorough testing on the matter,
but I'm perfectly comfortable with the previously provided function.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL