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
> 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 applic
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
Simon Riggs wrote:
> > > The way forward seems safest if this is a command, not an external
> > > executable. e.g. ALTER SYSTEM STOP BACKEND . That way we
> > have control
> > > over the implementation/porting, security, logging/audit.
> > Anybody that
> > > wants to can then wrap that in a script
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 convi
>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/
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 transac
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
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-abor
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.
> >
>
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
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 repo
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
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
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 convinc
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 repo
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 t
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
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-abor
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 norma
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 tr
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 n
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 (y
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 ta
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
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 co
"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
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 query
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
> 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 canc
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
"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
functio
> > 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
"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 qu
> >>> 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 inp
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
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...
>
>
"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 wh
> > 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
S
"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: Hav
>> 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 d
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 broadcast)--
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
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
-
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 unsub
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
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.
> 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 (fas
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,
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:
> 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 hav
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 SI
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Magnus Hagander wrote:
The function is pg_kill_backend(,). 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 pr
> -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
>>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(,). superuser-only,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> The function is pg_kill_backend(,). 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
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(,). superuse
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(,). superuser-only, of
course. Whic
58 matches
Mail list logo
