From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Rod Taylor <pg(at)rbt(dot)ca> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Server instrumentation for 8.1 |
Date: | 2005-06-05 03:37:14 |
Message-ID: | 200506050337.j553bEA05758@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Well, that's clear evidence that the only way we are going to be able to
SIGTERM a backend is it does a query cancel first, then terminates. I
don't think anything else is going to work cleanly.
---------------------------------------------------------------------------
Rod Taylor wrote:
> > > 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.
>
> --
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-06-05 03:40:48 | Re: [HACKERS] WAL: O_DIRECT and multipage-writer (+ memory |
Previous Message | Rod Taylor | 2005-06-05 03:25:09 | Re: Server instrumentation for 8.1 |