> > 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.
I've also used it regularly for a few years with 100 active connections
in order to get rid of processes which were doing things they shouldn't
be, and have run into problems.
It seems about one out of every 20 kills of something holding a heavy
lock (VACUUM, ALTER TABLE, etc.) will result in a lock table corruption
being reported within the next few hours, although the pg_locks view
doesn't show anything interesting, nor do the locks appear to persist as
other processes can use the structures.
--
