Bruce Momjian [EMAIL PROTECTED] writes:
On first glance, I don't see anything dangerous about SIGTERM.
You haven't thought about it very hard :-(
The major difference I see is that elog(FATAL) will call proc_exit
directly from elog, rather than longjmp'ing back to PostgresMain.
The case that we
Otherwise, I'll stick by my assertion that idle connection management should
be done in the middleware and NOT by psql.
Perhaps it should be, but as PostgreSQL picks up more and more vendor
applications this is difficult for the person administrating the
database.
Consider a 3rd party
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Not having a way to kill backends is like having no way to kill a
process except rebooting the server.
Some people think that making a database hard to kill is a good thing.
Sure. But we're not talking about taking down the whole
On Fri, 2004-04-02 at 16:52, Magnus Hagander wrote:
Hi!
When debugging on win32, I've created myself a little function that I
feel should be added to the backend proper. While it adds a lot of
vlaue on win32, I think it adds quite a bit of value on non-win32
platforms as well...
The
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Seems like useful functionality. Right now, how does an administrator
kill another backend from psql? They can't.
The question to ask is should they be able to?
I think any such facility is inherently a security
In this case, SIGINT (query cancel) will not help, because
all locks held by the transaction will still be held.
Wrong.
Really?
[ experiments... ] My apologies --- you are correct about
the present behavior. If a SIGINT arrives while waiting for
client input, it's just
Magnus Hagander [EMAIL PROTECTED] writes:
if (query_running)
cancel_query
abort transaction
else if (idle in transaction)
abort transaction
else if (idle not in transaction)
graceful shutdown
or if that is too confusing?
Too hazardous. Say you meant to kill a slow query, only
if (query_running)
cancel_query
abort transaction
else if (idle in transaction)
abort transaction
else if (idle not in transaction)
graceful shutdown
or if that is too confusing?
Too hazardous. Say you meant to kill a slow query, only it
finishes just before you
Magnus Hagander [EMAIL PROTECTED] writes:
If we are going to allow session kill then of course we need
PID for that.
I still say we need this.
Well, that seems to be the consensus, so I won't stand in the way.
If you like the cancel-by-XID idea then I'd suggest providing two
functions:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If we are going to allow session kill then of course we need
PID for that.
I still say we need this.
Well, that seems to be the consensus, so I won't stand in the way.
If you like the cancel-by-XID idea then I'd suggest
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If we are going to allow session kill then of course we need
PID for that.
I still say we need this.
Well, that seems to be the consensus, so I won't stand in the way.
If you like the cancel-by-XID idea then I'd
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
But are you saying it *is* safe with SIGTERM to a backend?
I'm saying I'm not happy about promoting that to the status of a
supported feature. Up to now it's always been if it breaks you
get to keep both pieces, but if there's a
Bruce Momjian [EMAIL PROTECTED] writes:
I assume admins are already doing this (via kill), so whether it is
supported or not, we should give folks a safe way to do this.
I don't think it's an open-and-shut decision as to whether people
actually *need* to do session kills (as opposed to
Magnus Hagander [EMAIL PROTECTED] writes:
But are you saying it *is* safe with SIGTERM to a backend?
I'm saying I'm not happy about promoting that to the status of a
supported feature. Up to now it's always been if it breaks you
get to keep both pieces, but if there's a built-in function to do
Josh Berkus wrote:
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
Bruce,
Someone already posted some pseudocode where they wanted to kill idle
backends, perhaps as part of connection pooling.
I'm not talking about code. I'm talking about a *reason*.
i.e.: I'm administrator of the blah-blah project. We had a lot of trouble
managing idle connections to
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
Bruce,
OK, you have a runaway report. You want to stop it. Query cancel is
only going to stop the current query, and once you do that the next
query is fed in so there is no way to actually stop the report,
especially if the report is not being run from the same machine as the
server (you
Josh Berkus [EMAIL PROTECTED] writes:
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.
Quite honestly, I don't know. We know that some people have done manual
SIGTERMs and not
Josh Berkus wrote:
Bruce,
Someone already posted some pseudocode where they wanted to kill idle
backends, perhaps as part of connection pooling.
I'm not talking about code. I'm talking about a *reason*.
i.e.: I'm administrator of the blah-blah project. We had a lot of trouble
Bruce Momjian [EMAIL PROTECTED] writes:
If there is a problem, maybe we can fix it, or perhap have the kill
function use SIGINT, then wait for the query to cancel, then SIGTERM.
Well, if someone could prove that the SIGTERM path is equivalent to
a transaction-aborting error followed by normal
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
If there is a problem, maybe we can fix it, or perhap have the kill
function use SIGINT, then wait for the query to cancel, then SIGTERM.
Well, if someone could prove that the SIGTERM path is equivalent to
a transaction-aborting
Josh Berkus wrote:
Bruce,
OK, you have a runaway report. You want to stop it. Query cancel is
only going to stop the current query, and once you do that the next
query is fed in so there is no way to actually stop the report,
especially if the report is not being run from the same
Bruce Momjian [EMAIL PROTECTED] writes:
OK, you have a runaway report. You want to stop it. Query cancel is
only going to stop the current query, and once you do that the next
query is fed in so there is no way to actually stop the report,
especially if the report is not being run from the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, you have a runaway report. You want to stop it. Query cancel is
only going to stop the current query, and once you do that the next
query is fed in so there is no way to actually stop the report,
especially if the report is not
pgman wrote:
Josh Berkus wrote:
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
Bruce Momjian [EMAIL PROTECTED] writes:
Not having a way to kill backends is like having no way to kill a
process except rebooting the server.
Some people think that making a database hard to kill is a good thing.
regards, tom lane
---(end of
On Tue, 2004-04-06 at 15:23, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
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.
So like I say, I'm hesitant to buy into
On Tue, 2004-04-06 at 15:10, Josh Berkus wrote:
Bruce,
OK, you have a runaway report. You want to stop it. Query cancel is
only going to stop the current query, and once you do that the next
query is fed in so there is no way to actually stop the report,
especially if the report is not
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Not having a way to kill backends is like having no way to kill a
process except rebooting the server.
Some people think that making a database hard to kill is a good thing.
I can't argue with that. :-)
I am researching the SIGTERM
Rod Taylor wrote:
On Tue, 2004-04-06 at 15:23, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
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.
So like I say,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
If there is a problem, maybe we can fix it, or perhap have the kill
function use SIGINT, then wait for the query to cancel, then SIGTERM.
Well, if someone could prove that the SIGTERM path is equivalent to
a transaction-aborting
The function to kill backend seems no longer in doubt, but the
*reason* is still blurred, other than we don't want to bring down the
postmaster to do this.
So far, reasons given have been:
1. to kill idlers
2. to kill runaway queries/statements, which has transaction
implications
I'd like to be
Simon Riggs wrote:
The function to kill backend seems no longer in doubt, but the
*reason* is still blurred, other than we don't want to bring down the
postmaster to do this.
So far, reasons given have been:
1. to kill idlers
2. to kill runaway queries/statements, which has transaction
Bruce Momjian
Simon Riggs wrote:
The function to kill backend seems no longer in doubt, but the
*reason* is still blurred, other than we don't want to
bring down the
postmaster to do this.
So far, reasons given have been:
1. to kill idlers
2. to kill runaway queries/statements,
Bruce Momjian wrote:
pgman wrote:
Josh Berkus wrote:
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
Simon Riggs wrote:
The way forward seems safest if this is a command, not an external
executable. e.g. ALTER SYSTEM STOP BACKEND x. That way we
have control
over the implementation/porting, security, logging/audit.
Anybody that
wants to can then wrap that in a script if they
In this case, SIGINT (query cancel) will not help, because
all locks
held by the transaction will still be held.
Wrong.
Really?
Please point out where I am wrong in this:
SESSION A: BEGIN TRANSACTION
SESSION A: LOCK TABLE foo IN ACCESS EXCLUSIVE MODE
SESSION
Magnus Hagander [EMAIL PROTECTED] writes:
In this case, SIGINT (query cancel) will not help, because
all locks held by the transaction will still be held.
Wrong.
Really?
[ experiments... ] My apologies --- you are correct about the present
behavior. If a SIGINT arrives while waiting
Killing backends with runaway queries is a routine administrative
task.
Cancelling runaway queries is a routine task. I'm less
convinced that a
remote kill (ie SIGTERM) facility is such a great idea.
Consider a scenario like:
User A starts transaction.
User A issues a LOCK TABLE (or does
Magnus Hagander [EMAIL PROTECTED] writes:
In this case, SIGINT (query cancel) will not help, because all locks
held by the transaction will still be held.
Wrong.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you
Tom Lane wrote:
it would definitely need to be a lot more constrained than
send-any-signal-to-any-postgres-process ... even for a superuser,
that's a mighty fat-gauge foot-gun.
What sort of constraints do you have in mind?
I'd limit it to SIGINT (query cancel) and SIGTERM (fast shutdown),
Tom,
Seems like useful functionality. Right now, how does an administrator
kill another backend from psql? They can't.
The question to ask is should they be able to?
And the answer is, Yes.
This is a commonly requested feature by DBA's migrating from SQL Server and
Oracle.In those
This is a commonly requested feature by DBA's migrating from SQL Server and
Oracle.In those databases, there is a GUI to monitor database requests,
and potentially kill them to resolve deadlocks or runaway queries (though, in
the case of SQL server, it does not work). Right now, it is very
On 2-Apr-04, at 5:16 PM, Andrew Dunstan wrote:
If' we're going to have this shouldn't it be a proper command?
Why? What benefit would this offer over implementing this feature as a
function?
-Neil
---(end of broadcast)---
TIP 1: subscribe and
Josh Berkus [EMAIL PROTECTED] writes:
Killing backends with runaway queries is a routine administrative
task.
Cancelling runaway queries is a routine task. I'm less convinced that a
remote kill (ie SIGTERM) facility is such a great idea.
regards, tom lane
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Killing backends with runaway queries is a routine administrative
task.
Cancelling runaway queries is a routine task. I'm less convinced that a
remote kill (ie SIGTERM) facility is such a great idea.
Of course, cancelling runaway queries
Neil Conway said:
On 2-Apr-04, at 5:16 PM, Andrew Dunstan wrote:
If' we're going to have this shouldn't it be a proper command?
Why? What benefit would this offer over implementing this feature as a
function?
psql help
cheers
andrew
---(end of
Hi!
When debugging on win32, I've created myself a little function that I
feel should be added to the backend proper. While it adds a lot of
vlaue on win32, I think it adds quite a bit of value on non-win32
platforms as well...
The function is pg_kill_backend(pid,signal). superuser-only, of
Magnus Hagander wrote:
Hi!
When debugging on win32, I've created myself a little function that I
feel should be added to the backend proper. While it adds a lot of
vlaue on win32, I think it adds quite a bit of value on non-win32
platforms as well...
The function is pg_kill_backend(pid,signal).
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
The function is pg_kill_backend(pid,signal). superuser-only, of
course. Which simply sends a signal to the specified backend -
querycancel, terminate, etc.
If' we're going to have this shouldn't it be a proper command? And maybe
Hi!
When debugging on win32, I've created myself a little function that I
feel should be added to the backend proper. While it adds a lot of
vlaue on win32, I think it adds quite a bit of value on non-win32
platforms as well...
The function is pg_kill_backend(pid,signal). superuser-only, of
-Original Message-
From: Magnus Hagander [mailto:[EMAIL PROTECTED]
Sent: Friday, April 02, 2004 2:34 PM
To: Andrew Dunstan; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Function to kill backend
Hi!
When debugging on win32, I've created myself a little
function that I
feel
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
The function is pg_kill_backend(pid,signal). superuser-only, of
course. Which simply sends a signal to the specified backend -
querycancel, terminate, etc.
If' we're going to have this shouldn't it
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
it would definitely need to be a lot more constrained than
send-any-signal-to-any-postgres-process ... even for a superuser,
that's a mighty fat-gauge foot-gun.
What sort of constraints do you have in mind?
I'd limit it to SIGINT
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
it would definitely need to be a lot more constrained than
send-any-signal-to-any-postgres-process ... even for a superuser,
that's a mighty fat-gauge foot-gun.
What sort of constraints do you have in mind?
Bruce Momjian [EMAIL PROTECTED] writes:
Seems like useful functionality. Right now, how does an administrator
kill another backend from psql? They can't.
The question to ask is should they be able to?
I think any such facility is inherently a security risk, since it means
that a remote
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Seems like useful functionality. Right now, how does an administrator
kill another backend from psql? They can't.
The question to ask is should they be able to?
I think any such facility is inherently a security risk, since it
58 matches
Mail list logo
