On Sun, 2010-01-03 at 11:55 +0100, Martijn van Oosterhout wrote:
On Fri, Jan 01, 2010 at 03:31:58PM -0500, Kris Jurka wrote:
The JDBC driver does want cancel if active behavior. The JDBC API
specifies Statement.cancel() where Statement is running one particular
backend query. So it
On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
CancelRequest's behaviour currently equates to SIGINT, so
processCancelRequest() can only use SIGINT if SIGINT's behaviour remains
same.
I would recommend we make SIGINT do cancel-anything, and handle
everything else
On Wed, Jan 6, 2010 at 4:37 PM, Joachim Wieland j...@mcknight.de wrote:
On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
CancelRequest's behaviour currently equates to SIGINT, so
processCancelRequest() can only use SIGINT if SIGINT's behaviour remains
same.
I would
On Fri, Jan 01, 2010 at 03:31:58PM -0500, Kris Jurka wrote:
The JDBC driver does want cancel if active behavior. The JDBC API
specifies Statement.cancel() where Statement is running one particular
backend query. So it really does want to cancel just that one query.
Already this is
On Fri, Jan 1, 2010 at 1:39 PM, Simon Riggs si...@2ndquadrant.com wrote:
Interesting. It's not obvious to me how killing an *idle* session can
resolve a deadlock. AIUI a deadlock requires a cycle in the waits-for
graph, and an idle transaction is not waiting for a lock acquisition.
In strict
Hi,
Simon Riggs wrote:
In practice, many lock contention situations are caused by long running
idle transactions, so having a deadlock detector be able to resolve a
situation by deciding that an idle xact is actually in some kind of wait
state would be very useful.
Hm.. so you'd abort the
Simon Riggs wrote:
Attached is the patch I intend to commit, barring objections.
This patch extends SIGINT to allow cancellation of transactions while
idle in both HS and normal mode.
How does AbortTransactionAndAnySubtransactions() differ from
AbortOutOfAnyTransaction()? Having followed the
On Fri, 2010-01-01 at 12:53 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Attached is the patch I intend to commit, barring objections.
This patch extends SIGINT to allow cancellation of transactions while
idle in both HS and normal mode.
How does
On Jan 1, 2010, at 6:48 AM, Simon Riggs si...@2ndquadrant.com w
We could either endlessly repeat this
ERROR: current transaction is aborted because of conflict with
recovery, commands ignored until end of transaction block
+1 for this option.
I'm also not sure why we would want to single
Simon Riggs wrote:
On Fri, 2010-01-01 at 12:53 +0200, Heikki Linnakangas wrote:
I agree with Joachim's comments upthread that we should have a different
function for forcefully aborting the whole transaction, and leave the
current pg_cancel_backend() behavior alone.
That would require
On Fri, Jan 1, 2010 at 8:38 PM, Robert Haas robertmh...@gmail.com wrote:
On Jan 1, 2010, at 6:48 AM, Simon Riggs si...@2ndquadrant.com w
We could either endlessly repeat this
ERROR: current transaction is aborted because of conflict with
recovery, commands ignored until end of transaction
On Fri, 2010-01-01 at 07:08 -0800, Robert Haas wrote:
On Jan 1, 2010, at 6:48 AM, Simon Riggs si...@2ndquadrant.com w
We could either endlessly repeat this
ERROR: current transaction is aborted because of conflict with
recovery, commands ignored until end of transaction block
+1 for
On Jan 1, 2010, at 8:30 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-01-01 at 07:08 -0800, Robert Haas wrote:
On Jan 1, 2010, at 6:48 AM, Simon Riggs si...@2ndquadrant.com w
We could either endlessly repeat this
ERROR: current transaction is aborted because of conflict with
On Fri, 2010-01-01 at 17:14 +0200, Heikki Linnakangas wrote:
Which amounts to rejecting this patch, since *this* patch changes the
behaviour of SIGINT for all senders, which is what I understood people
desired, i.e. not just a change for Hot Standby. I assumed Joachim did
not mean to veto
On Fri, 2010-01-01 at 09:24 -0800, Robert Haas wrote:
If we have other events that can asynchronously roll back a
transaction, I would think they would deserve similar handling. Off
the top of my head, I'm not sure if there are any such cases.
Serialization failures, deadlocks,
On Jan 1, 2010, at 9:42 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-01-01 at 09:24 -0800, Robert Haas wrote:
If we have other events that can asynchronously roll back a
transaction, I would think they would deserve similar handling.
Off
the top of my head, I'm not sure if
On Fri, 2010-01-01 at 10:15 -0800, Robert Haas wrote:
Hmm. I don't think I can get a serialization failure, deadlock, or
out
of memory error while my session is idle.
Agreed. As a point of note, now that we can cancel idle transactions
there isn't any future blocker from making
On Thu, 31 Dec 2009, Simon Riggs wrote:
On Thu, 2009-12-31 at 15:41 +0100, Joachim Wieland wrote:
I still think that we should have three transaction cancel modes, one
to cancel an idle transaction, another one to cancel a running query
and a third one that just cancels the transaction
On Fri, 2010-01-01 at 15:31 -0500, Kris Jurka wrote:
On Thu, 31 Dec 2009, Simon Riggs wrote:
On Thu, 2009-12-31 at 15:41 +0100, Joachim Wieland wrote:
I still think that we should have three transaction cancel modes, one
to cancel an idle transaction, another one to cancel a running
On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
I would recommend we make SIGINT do cancel-anything, and handle
everything else via SIGUSR1, including CancelRequest. I'm not going to
do that; I'm going to make HS conflict resolution work, which means
putting in enough
On Thu, 2009-12-24 at 21:38 +0100, Joachim Wieland wrote:
On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We are using NOTICE, not NOTIFY, assuming that we use anything at all
(which I still regard as unnecessary). Please stop injecting confusion
into the discussion.
On Thu, 2009-12-31 at 11:10 +, Simon Riggs wrote:
On Thu, 2009-12-24 at 21:38 +0100, Joachim Wieland wrote:
On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We are using NOTICE, not NOTIFY, assuming that we use anything at all
(which I still regard as unnecessary).
On Thu, Dec 31, 2009 at 3:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
This patch extends SIGINT to allow cancellation of transactions while
idle in both HS and normal mode. It also changes the standard message
reported on an idle transaction in aborted state to 'IDLE in
transaction
On Thu, 2009-12-31 at 15:41 +0100, Joachim Wieland wrote:
I still think that we should have three transaction cancel modes, one
to cancel an idle transaction, another one to cancel a running query
and a third one that just cancels the transaction regardless of it
being idle or not. This last
On Tue, 29 Dec 2009, Simon Riggs wrote:
The proposal is to send an additional NOTICE to the client and abort
all open transactions and subtransactions (this is what I got from the
previous discussion).
Would this work with JDBC driver and/or general protocol clients?
A Notice would be
On Wed, Dec 30, 2009 at 12:28 AM, Simon Riggs si...@2ndquadrant.com wrote:
I had to write an additional function AbortAnyTransaction() which
aborts all transactions and subtransactions and leaves the transaction
in the aborted state, is there an existing function to do this?
On Wed, 2009-12-30 at 05:02 -0500, Kris Jurka wrote:
On Tue, 29 Dec 2009, Simon Riggs wrote:
The proposal is to send an additional NOTICE to the client and abort
all open transactions and subtransactions (this is what I got from the
previous discussion).
Would this work with JDBC
On Wed, 2009-12-30 at 11:43 +0100, Joachim Wieland wrote:
On Wed, Dec 30, 2009 at 12:28 AM, Simon Riggs si...@2ndquadrant.com wrote:
I had to write an additional function AbortAnyTransaction() which
aborts all transactions and subtransactions and leaves the transaction
in the aborted state,
Simon Riggs wrote:
On Wed, 2009-12-30 at 05:02 -0500, Kris Jurka wrote:
On Tue, 29 Dec 2009, Simon Riggs wrote:
The proposal is to send an additional NOTICE to the client and abort
all open transactions and subtransactions (this is what I got from the
previous discussion).
Would this work
On Wed, 30 Dec 2009, Simon Riggs wrote:
http://developer.postgresql.org/pgdocs/postgres/protocol-flow.html#PROTOCOL-ASYNC
It is possible for NoticeResponse messages to be generated due to
outside activity; for example, if the database administrator commands a
fast database shutdown, the
On Wed, 30 Dec 2009, Heikki Linnakangas wrote:
Could we send an asynchronous notification immediately when the
transaction is cancelled, but also change the error message you get in
the subsequent commands. Clients that ignore the async notification
would still see a proper error message at
On 30/12/2009 7:37 PM, Simon Riggs wrote:
Can JDBC accept a NOTICE, yet throw an error? NOTICEs have a SQLState
field just like ERRORs do, so you should be able to special case that.
The JDBC driver would have to throw when the app code next interacted
with the connection object anyway. It
Craig Ringer cr...@postnewspapers.com.au wrote:
It might be kind of handy if I could getWarnings() on the
connection object without blocking so I could call it before I
executed a statement on the connection ... but that'd always
introduce a race between transaction cancellation/timeout and
On Wed, 2009-12-30 at 14:15 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
AFAIK, NOTICE was suggested because it can be sent at any time, whereas
ERRORs are only associated with statements.
http://developer.postgresql.org/pgdocs/postgres/protocol-flow.html#PROTOCOL-ASYNC
It is
On Thu, 2009-12-24 at 21:38 +0100, Joachim Wieland wrote:
On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We are using NOTICE, not NOTIFY, assuming that we use anything at all
(which I still regard as unnecessary). Please stop injecting confusion
into the discussion.
On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We are using NOTICE, not NOTIFY, assuming that we use anything at all
(which I still regard as unnecessary). Please stop injecting confusion
into the discussion.
Attached is a minimal POC patch that allows to cancel an idle
On Sun, 2009-12-06 at 07:58 +, Simon Riggs wrote:
On Sat, 2009-12-05 at 18:13 -0700, James Pye wrote:
On Dec 5, 2009, at 12:25 PM, Simon Riggs wrote:
...
I'm not volunteering here, but having worked with the protocol, I do have a
suggestion:
Thanks. Looks like good input. With
On Dec 6, 2009, at 2:58 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2009-12-05 at 18:13 -0700, James Pye wrote:
On Dec 5, 2009, at 12:25 PM, Simon Riggs wrote:
...
I'm not volunteering here, but having worked with the protocol, I
do have a suggestion:
Thanks. Looks like good
Hannu Krosing ha...@2ndquadrant.com writes:
On Sun, 2009-12-06 at 07:58 +, Simon Riggs wrote:
Thanks. Looks like good input. With the further clarification that we
use NOTIFY it seems a solution is forming.
If we use notify, then the sufficiently smart client (tm) should
probably
I'd be very grateful to any hackers out there who are looking for a
project before close of 8.5 to consider working on this. It's dang
useful, both for Hot Standby and normal processing.
(You'll have the added bonus of proving you're smarter than me!)
On Wed, 2009-01-21 at 15:22 -0500, Bruce
On Dec 5, 2009, at 12:25 PM, Simon Riggs wrote:
...
I'm not volunteering here, but having worked with the protocol, I do have a
suggestion:
This allows locks to be released, but it is complex to report the
cancellation back to the client.
I think the answer here is that
On Sat, Dec 5, 2009 at 8:13 PM, James Pye li...@jwp.name wrote:
I think the answer here is that the server should *not* report the
cancellation.
Rather, it should mark the transaction as failed and let the client
eventually sync its state on subsequent requests that will result in
Robert Haas robertmh...@gmail.com writes:
I think this line of thinking is on the right track. The server
should certainly not send back an immediate ERROR response, because
that will definitely confuse the client. Of course, any subsequent
commands will report ERRORs until the client rolls
On Sat, Dec 5, 2009 at 10:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think this line of thinking is on the right track. The server
should certainly not send back an immediate ERROR response, because
that will definitely confuse the client. Of
On Sat, 2009-12-05 at 18:13 -0700, James Pye wrote:
On Dec 5, 2009, at 12:25 PM, Simon Riggs wrote:
...
I'm not volunteering here, but having worked with the protocol, I do have a
suggestion:
Thanks. Looks like good input. With the further clarification that we
use NOTIFY it seems a
Added to TODO:
Allow administrators to cancel multi-statement idle
transactions
This allows locks to be released, but it is complex to report the
cancellation back to the client.
*
Simon Riggs wrote:
On Wed, 2009-01-21 at 15:22 -0500, Bruce Momjian wrote:
Added to TODO:
Allow administrators to cancel multi-statement idle
transactions
This allows locks to be released, but it is complex to report the
cancellation back to the
On Wed, 2009-01-21 at 15:46 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2009-01-21 at 15:22 -0500, Bruce Momjian wrote:
Added to TODO:
Allow administrators to cancel multi-statement idle
transactions
This allows locks to be released, but it is
Joshua D. Drake wrote:
On Wed, 2009-01-21 at 15:46 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2009-01-21 at 15:22 -0500, Bruce Momjian wrote:
Added to TODO:
Allow administrators to cancel multi-statement idle
transactions
49 matches
Mail list logo
