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.
On Wed, Jan 6, 2010 at 4:37 PM, Joachim Wieland wrote:
> On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs 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
On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs 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 via SIGUSR1, incl
On Fri, Jan 1, 2010 at 1:39 PM, Simon Riggs 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 theory, yes.
>
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
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
On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs 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 infrastructure to
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
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 regar
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 fro
On Jan 1, 2010, at 9:42 AM, Simon Riggs 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 there are any such cases.
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, deadlo
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
On Jan 1, 2010, at 8:30 AM, Simon Riggs wrote:
On Fri, 2010-01-01 at 07:08 -0800, Robert Haas wrote:
On Jan 1, 2010, at 6:48 AM, Simon Riggs w
We could either endlessly repeat this
ERROR: current transaction is aborted because of conflict with
recovery, commands ignored until end of transac
On Fri, 2010-01-01 at 07:08 -0800, Robert Haas wrote:
> On Jan 1, 2010, at 6:48 AM, Simon Riggs 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.
On Fri, Jan 1, 2010 at 8:38 PM, Robert Haas wrote:
> On Jan 1, 2010, at 6:48 AM, Simon Riggs 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.
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 requ
On Jan 1, 2010, at 6:48 AM, Simon Riggs 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 out Hot Standby to
gene
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 AbortTransactionAndAn
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
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 la
On Thu, Dec 31, 2009 at 3:03 PM, Simon Riggs 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 ' in
> transaction (aborted)', so that once abor
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 wrote:
> > > We are using NOTICE, not NOTIFY, assuming that we use anything at all
> > > (which I still regard as unnecessary). Please sto
On Thu, 2009-12-24 at 21:38 +0100, Joachim Wieland wrote:
> On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane 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 i
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-ASY
Craig Ringer 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
> statement execution, s
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 ca
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 th
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 bac
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).
>>
On Wed, 2009-12-30 at 11:43 +0100, Joachim Wieland wrote:
> On Wed, Dec 30, 2009 at 12:28 AM, Simon Riggs 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
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 wo
On Wed, Dec 30, 2009 at 12:28 AM, Simon Riggs 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?
>
> AbortOutOfAnyTransaction()
But
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 eas
On Thu, 2009-12-24 at 21:38 +0100, Joachim Wieland wrote:
> On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane 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 i
On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane 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
transaction with S
Hannu Krosing 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 declared that it is
On Dec 6, 2009, at 2:58 AM, 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 the further
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 goo
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
On Sat, Dec 5, 2009 at 10:15 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 back. But it also
On Sat, Dec 5, 2009 at 8:13 PM, James Pye 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
> InFailedTransact
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 t
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 Momj
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
> > > > tr
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 r
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
> > cancellatio
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 client.
>
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.
*
http://archives.postgresql.org/pg
Currently SIGINT is ignored during in transaction, but we have
recently agreed to allow this to cancel the transaction. We said we
would do this in all cases, so this is a separate feature/patch (though
Hot Standby requires it).
A simple change allows the transaction to be cancelled, but there ar
51 matches
Mail list logo
