"Craig A. James" <[EMAIL PROTECTED]> writes:
> It's also possible that the INSERT itself is the problem, or adds to the
> problem. The SIGINT may come after a few million rows have been inserted, so
> it would have to clean that up, right?
No, because we don't use UNDO. The next VACUUM would h
Tom Lane wrote:
"Craig A. James" <[EMAIL PROTECTED]> writes:
Bottom line is that I was expecting "instant death" with SIGTERM, but
instead got an agonizing, drawn out -- but safe -- death of the query.
What was the query exactly?
Our expectation is that all or at least most queries should res
Hi, Tom,
Tom Lane wrote:
> Our expectation is that all or at least most queries should respond to
> SIGINT or SIGTERM interrupts pretty rapidly, say on a less-than-a-second
> timescale. However there are various loops in the backend that fail to
> execute CHECK_FOR_INTERRUPTS sufficiently often :
"Craig A. James" <[EMAIL PROTECTED]> writes:
> Bottom line is that I was expecting "instant death" with SIGTERM, but
> instead got an agonizing, drawn out -- but safe -- death of the query.
What was the query exactly?
Our expectation is that all or at least most queries should respond to
SIGINT o
Steinar H. Gunderson wrote:
On Wed, Jul 12, 2006 at 08:43:18AM -0700, Craig A. James wrote:
Then you killed the wrong backend...
No queries run in postmaster. They all run in postgres backends. The
postmaster does very little actual work, other than keeping track of
everybody else.
It turns out
Thanks for your reply, Mark:
I'm back to my original question: How do you kill a runaway query
without bringing down the whole database? Is there really no answer
to this?
... if you actually want to disconnect a backend
process then there is nothing to let you do this remotely. I recently
Craig A. James wrote:
I'm back to my original question: How do you kill a runaway query
without bringing down the whole database? Is there really no answer to
this?
As others have mentioned, pg_cancel_backend(pid) will stop query
execution by backend process id 'pid'.
While this is of
Craig A. James wrote:
> Magnus Hagander wrote:
>>> This raises the question: Why doesn't Postgres have a "kill session"
>>> command that works? Oracle has it, and it's invaluable; there is no
>>> substitute. Various writers to these PG lists have raised the
>>> question repeatedly. Is it just a
> > I beleive the function to kill a backend is actually in the
> codebase,
> > it's just commented out because it's considered dangerous.
> There are
> > some possible issues (see -hackers archives) about sending SIGTERM
> > without actually shutting down the whole cluster.
> >
> > Doing the
On Wed, Jul 12, 2006 at 08:43:18AM -0700, Craig A. James wrote:
>> Then you killed the wrong backend...
>> No queries run in postmaster. They all run in postgres backends. The
>> postmaster does very little actual work, other than keeping track of
>> everybody else.
>
> It turns out I was confused
Magnus Hagander wrote:
This raises the question: Why doesn't Postgres have a "kill
session" command that works? Oracle has it, and it's
invaluable; there is no substitute. Various writers to these
PG lists have raised the question repeatedly. Is it just a
matter that nobody has had the time
> There have been dozens, perhaps hundreds, of entries in the
> pg-admin, pg-general, and pg-performance lists regarding
> killing a session, but as far as I can tell, there is no
> Postgres solution. Did I miss something?
>
> This raises the question: Why doesn't Postgres have a "kill
> sess
Craig A. James wrote:
There have been dozens, perhaps hundreds, of entries in the pg-admin,
pg-general, and pg-performance lists regarding killing a session, but as
far as I can tell, there is no Postgres solution. Did I miss something?
This raises the question: Why doesn't Postgres have a "k
13 matches
Mail list logo
