From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | andrew(at)supernews(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Server instrumentation for 8.1 |
Date: | 2005-05-12 14:24:23 |
Message-ID: | 330.1115907863@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew - Supernews <andrew+nonews(at)supernews(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-12 14:33:43 | Re: SQL_ASCII vs. 7-bit ASCII encodings |
Previous Message | Alvaro Herrera | 2005-05-12 14:21:13 | Re: implementing NOTIFY with message parameter |