Re: Server instrumentation for 8.1

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

In response to

Browse pgsql-hackers by date

  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