Re: Server instrumentation for 8.1
| От | Robert Treat |
|---|---|
| Тема | Re: Server instrumentation for 8.1 |
| Дата | |
| Msg-id | 200505121629.02496.xzilla@users.sourceforge.net обсуждение исходный текст |
| Ответ на | Re: Server instrumentation for 8.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: