Re: Function to kill backend

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Function to kill backend
Date: 2004-04-06 16:22:19
Message-ID: 200404060922.19511.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom,

> I don't think it's an open-and-shut decision as to whether people
> actually *need* to do session kills (as opposed to query/transaction
> kills). The arguments presented so far are not convincing to my mind,
> certainly not convincing enough to buy into a commitment to do whatever
> it takes to support that.

Hmmm ... well, I can make a real-world case from my supported apps for
transaction/statement kills. But my support for session kills is just
hypothetical; any time I've had to kill off sessions, it's because I had to
shut the database down, and that's better done from the command line.

My web apps which need to manage the number of connections do it through their
connection pool.

So I would vote for Yes on SIGINT by XID, but No on SIGTERM by PID, if Tom
thinks there will be any significant support & troubleshooting involved for
the latter.

Unless, of course, someone can give us a real business case that they have
actually encountered in production.

--
Josh Berkus
Aglio Database Solutions
San Francisco

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2004-04-06 17:44:37 Re: pg_hba.conf view from the database?
Previous Message Andrew Dunstan 2004-04-06 16:04:48 Re: [HACKERS] logging statement levels