Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-14 Thread Andres Freund
On Wednesday 13 January 2010 00:07:53 Simon Riggs wrote: > On Tue, 2010-01-12 at 19:43 +0100, Andres Freund wrote: > > On Tuesday 12 January 2010 09:40:03 Simon Riggs wrote: > > > On Tue, 2010-01-12 at 06:30 +0100, Andres Freund wrote: > > > > Currently the patch does not yet do anything to avoid l

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-12 Thread Simon Riggs
On Tue, 2010-01-12 at 19:43 +0100, Andres Freund wrote: > On Tuesday 12 January 2010 09:40:03 Simon Riggs wrote: > > On Tue, 2010-01-12 at 06:30 +0100, Andres Freund wrote: > > > Currently the patch does not yet do anything to avoid letting the > > > protocol out of sync. What do you think about ad

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-12 Thread Andres Freund
Hi, The thought was that it might be helpful to be able to raise NOTICE or DEBUG* as well - but admitedly there is not a big need for it... Andres -- Sent from a mobile phone - please excuse brevity and formatting. - Ursprüngliche Mitteilung - > Andres Freund writes: > > On Tuesday 12 J

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-12 Thread Tom Lane
Andres Freund writes: > On Tuesday 12 January 2010 09:40:03 Simon Riggs wrote: >>> So that one could do an elog(ERROR & ERROR_NO_SEND_CLIENT, .. or such? > Do you aggree on the approach then? Do you want to do it? Why not use the already-existing COMMERROR thing? regard

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-12 Thread Andres Freund
On Tuesday 12 January 2010 09:40:03 Simon Riggs wrote: > On Tue, 2010-01-12 at 06:30 +0100, Andres Freund wrote: > > Currently the patch does not yet do anything to avoid letting the > > protocol out of sync. What do you think about adding a flag for error > > codes not to communicate with the clie

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-12 Thread Andres Freund
On 01/12/10 09:40, Simon Riggs wrote: On Tue, 2010-01-12 at 06:30 +0100, Andres Freund wrote: On 01/07/10 22:37, Andres Freund wrote: On Thursday 07 January 2010 22:28:46 Tom Lane wrote: Andres Freund writes: I did not want to suggest using Simons code there. Sorry for the brevity. should h

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-12 Thread Simon Riggs
On Tue, 2010-01-12 at 06:30 +0100, Andres Freund wrote: > On 01/07/10 22:37, Andres Freund wrote: > > On Thursday 07 January 2010 22:28:46 Tom Lane wrote: > >> Andres Freund writes: > >>> I did not want to suggest using Simons code there. Sorry for the brevity. > >>> should have read as "revert to

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-11 Thread Andres Freund
On 01/07/10 22:37, Andres Freund wrote: On Thursday 07 January 2010 22:28:46 Tom Lane wrote: Andres Freund writes: I did not want to suggest using Simons code there. Sorry for the brevity. should have read as "revert to old code and add two step killing (thats likely around 10 lines or so)".

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-11 Thread Andres Freund
On 01/07/10 22:37, Andres Freund wrote: On Thursday 07 January 2010 22:28:46 Tom Lane wrote: Andres Freund writes: I did not want to suggest using Simons code there. Sorry for the brevity. should have read as "revert to old code and add two step killing (thats likely around 10 lines or so)".

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Andres Freund
On Thursday 07 January 2010 22:28:46 Tom Lane wrote: > Andres Freund writes: > > I did not want to suggest using Simons code there. Sorry for the brevity. > > should have read as "revert to old code and add two step killing (thats > > likely around 10 lines or so)". > > > > "two step killing" mean

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Tom Lane
Andres Freund writes: > I did not want to suggest using Simons code there. Sorry for the brevity. > should have read as "revert to old code and add two step killing (thats > likely > around 10 lines or so)". > "two step killing" meaning that we signal ERROR for a few times and if > nothing >

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Andres Freund
On Thursday 07 January 2010 21:47:47 Tom Lane wrote: > Andres Freund writes: > > The reason I suggested adding CHECK_FOR_INTERRUPTS into the recv code > > path was that it should allow a relatively "natural" handling of > > canceling "IDLE IN TRANSACTION" queries without doing anything in the > >

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Tom Lane
Andres Freund writes: > The reason I suggested adding CHECK_FOR_INTERRUPTS into the recv code path > was > that it should allow a relatively "natural" handling of canceling "IDLE IN > TRANSACTION" queries without doing anything in the interrupt handler. > I think it shouldn't be to hard to mak

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Andres Freund
On Thursday 07 January 2010 19:49:59 Tom Lane wrote: > Andres Freund writes: > > Stupid question: > > > > Why dont we add CHECK_FOR_INTERRUPTS (or something similar) to everything > > calling recv (especially in the EINTR) case? > > We pretty much have CHECK_FOR_INTERRUPTS everywhere that it's sa

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Tom Lane
Joachim Wieland writes: > On Thu, Jan 7, 2010 at 7:12 PM, Tom Lane wrote: >> As far as I can think at the moment, the best you can do is throw the >> elog(ERROR), and if control gets out to the error recovery block in >> PostgresMain, you can force a transaction abort there.  In other words, >> p

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Joachim Wieland
On Thu, Jan 7, 2010 at 7:12 PM, Tom Lane wrote: > As far as I can think at the moment, the best you can do is throw the > elog(ERROR), and if control gets out to the error recovery block in > PostgresMain, you can force a transaction abort there.  In other words, > pretty much the same logic that

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Simon Riggs
On Thu, 2010-01-07 at 19:23 +0100, Andres Freund wrote: > On Thursday 07 January 2010 19:12:31 Tom Lane wrote: > > > > As far as I can think at the moment, the best you can do is throw the > > elog(ERROR), and if control gets out to the error recovery block in > > PostgresMain, you can force a tra

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Tom Lane
Andres Freund writes: > Stupid question: > Why dont we add CHECK_FOR_INTERRUPTS (or something similar) to everything > calling recv (especially in the EINTR) case? We pretty much have CHECK_FOR_INTERRUPTS everywhere that it's safe already. The problem here is not a lack of execution of CHECK_

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Simon Riggs
On Thu, 2010-01-07 at 13:12 -0500, Tom Lane wrote: > not fixed the fundamental problem. (I wasn't saying that I had, only wanted to confirm the problem still existed in the version I was currently working on.) > How critical is it that an > HS-requested query cancel be any more likely to do anyt

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Andres Freund
On Thursday 07 January 2010 19:12:31 Tom Lane wrote: > Simon Riggs writes: > > On Thu, 2010-01-07 at 12:14 -0500, Tom Lane wrote: > >> While we're discussing this: the current coding with > >> AbortOutOfAnyTransaction within ProcessInterrupts is *utterly* unsafe. > >> I realize that's just a toy p

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Tom Lane
Simon Riggs writes: > On Thu, 2010-01-07 at 12:14 -0500, Tom Lane wrote: >> While we're discussing this: the current coding with >> AbortOutOfAnyTransaction within ProcessInterrupts is *utterly* unsafe. >> I realize that's just a toy placeholder, but getting rid of it has to be >> on the list of s

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Simon Riggs
On Thu, 2010-01-07 at 12:14 -0500, Tom Lane wrote: > Simon Riggs writes: > > On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote: > >> @Simon: Is there a reason why you have not yet removed recoveryConflictMode > >> from PGPROC? > > > Unfortunately we still need a mechanism to mark which bac

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Tom Lane
Simon Riggs writes: > On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote: >> @Simon: Is there a reason why you have not yet removed recoveryConflictMode >> from PGPROC? > Unfortunately we still need a mechanism to mark which backends have been > cancelled already. Transaction state for virt

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Simon Riggs
On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote: > @Simon: Is there a reason why you have not yet removed recoveryConflictMode > from PGPROC? Unfortunately we still need a mechanism to mark which backends have been cancelled already. Transaction state for virtual transactions isn't visib

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Simon Riggs
On Thu, 2010-01-07 at 17:50 +0100, Joachim Wieland wrote: > On Thu, Jan 7, 2010 at 3:03 PM, Simon Riggs wrote: > > On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote: > >> I have reworked Simon's patch a bit and attach the result. > > > > Oh dear, this is exactly what I've been working on...

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Joachim Wieland
On Thu, Jan 7, 2010 at 3:03 PM, Simon Riggs wrote: > On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote: >> I have reworked Simon's patch a bit and attach the result. > > Oh dear, this is exactly what I've been working on... Sorry, as you have posted a first patch some days ago I thought yo

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Joachim Wieland
On Thu, Jan 7, 2010 at 4:23 PM, Tom Lane wrote: > Joachim Wieland writes: >> As there were so many boolean SomethingCancelPending variables I changed them >> to be bitmasks and merged all of them into a single variable. > > This seems like a truly horrid idea, because those variables are set by >

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Tom Lane
Joachim Wieland writes: > As there were so many boolean SomethingCancelPending variables I changed them > to be bitmasks and merged all of them into a single variable. This seems like a truly horrid idea, because those variables are set by signal handlers. A bitmask cannot be manipulated atomica

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Andres Freund
On Thursday 07 January 2010 14:45:55 Joachim Wieland wrote: > On Thu, Dec 31, 2009 at 6:40 PM, Simon Riggs wrote: > >> Building racy infrastructure when it can be avoided with a little care > >> still seems not to be the best path to me. > > > > Doing that will add more complexity in an area that

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Simon Riggs
On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote: > On Thu, Dec 31, 2009 at 6:40 PM, Simon Riggs wrote: > >> Building racy infrastructure when it can be avoided with a little care > >> still seems not to be the best path to me. > > > > Doing that will add more complexity in an area that is

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2010-01-07 Thread Joachim Wieland
On Thu, Dec 31, 2009 at 6:40 PM, Simon Riggs wrote: >> Building racy infrastructure when it can be avoided with a little care >> still seems not to be the best path to me. > > Doing that will add more complexity in an area that is hard to test > effectively. I think the risk of introducing further

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-31 Thread Simon Riggs
On Thu, 2009-12-31 at 13:14 +0100, Andres Freund wrote: > > > When cancelling a backend that behaviour could be a bit > annoying ;-) > > > > Reading comments alone doesn't show the full situation here. > > > > Before we send signal we check pid also, so the chances of this > > happening are fairl

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-31 Thread Andres Freund
On Thursday 31 December 2009 12:25:19 Simon Riggs wrote: > On Wed, 2009-12-30 at 20:06 +0100, Andres Freund wrote: > > Hm. I just read a bit of that multiplexing facility (out of a different > > reason) and I have some doubt about it being used unmodified for > > canceling backends: > > > > procsig

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-31 Thread Simon Riggs
On Wed, 2009-12-30 at 20:06 +0100, Andres Freund wrote: > Hm. I just read a bit of that multiplexing facility (out of a different > reason) > and I have some doubt about it being used unmodified for canceling backends: > > procsignal.c: > /* > * Note: Since there's no locking, it's possible th

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-30 Thread Andres Freund
On Thursday 31 December 2009 01:09:57 Robert Haas wrote: > On Wed, Dec 30, 2009 at 6:43 PM, Andres Freund wrote: > >> On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund wrote: > >> > On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote: > >> > > On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote:

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-30 Thread Robert Haas
On Wed, Dec 30, 2009 at 6:43 PM, Andres Freund wrote: > > - Ursprüngliche Mitteilung - >> On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund wrote: >> > On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote: >> > > On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote: >> > > > Andres Freund

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-30 Thread Andres Freund
- Ursprüngliche Mitteilung - > On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund wrote: > > On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote: > > > On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote: > > > > Andres Freund writes: > > > > > On Tuesday 29 December 2009 16:22:54 Tom Lan

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-30 Thread Robert Haas
On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund wrote: > On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote: >> On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote: >> > Andres Freund writes: >> > > On Tuesday 29 December 2009 16:22:54 Tom Lane wrote: >> > >> This seems like a fairly bad idea.

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-30 Thread Andres Freund
On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote: > On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote: > > Andres Freund writes: > > > On Tuesday 29 December 2009 16:22:54 Tom Lane wrote: > > >> This seems like a fairly bad idea. One of the intended use-cases is > > >> to be able to manua

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-30 Thread Simon Riggs
On Wed, 2009-12-30 at 12:05 +0100, Joachim Wieland wrote: > On Tue, Dec 29, 2009 at 4:22 PM, Tom Lane wrote: > > This seems like a fairly bad idea. One of the intended use-cases is to > > be able to manually "kill -INT" a misbehaving backend. Assuming that > > there will be valid info about the

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-30 Thread Joachim Wieland
On Tue, Dec 29, 2009 at 4:22 PM, Tom Lane wrote: > This seems like a fairly bad idea.  One of the intended use-cases is to > be able to manually "kill -INT" a misbehaving backend.  Assuming that > there will be valid info about the signal in shared memory will break > that. I never intended to ch

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-29 Thread Simon Riggs
On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote: > Andres Freund writes: > > On Tuesday 29 December 2009 16:22:54 Tom Lane wrote: > >> This seems like a fairly bad idea. One of the intended use-cases is to > >> be able to manually "kill -INT" a misbehaving backend. Assuming that > >> there wil

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-29 Thread Simon Riggs
On Tue, 2009-12-29 at 14:14 +0100, Joachim Wieland wrote: > haven't received a reply on it yet. Apologies for that. I replied today, just forgot to hit send until now. Thanks again for the patch. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hac

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-29 Thread Tom Lane
Andres Freund writes: > On Tuesday 29 December 2009 16:22:54 Tom Lane wrote: >> This seems like a fairly bad idea. One of the intended use-cases is to >> be able to manually "kill -INT" a misbehaving backend. Assuming that >> there will be valid info about the signal in shared memory will break

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-29 Thread Andres Freund
On Tuesday 29 December 2009 16:22:54 Tom Lane wrote: > Joachim Wieland writes: > > If we use the same signal for both cases, the receiving backend cannot > > tell what the intention of the sending backend was. That's why I > > proposed to make SIGINT similar to SIGUSR1 where we write a reason to >

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-29 Thread Tom Lane
Joachim Wieland writes: > If we use the same signal for both cases, the receiving backend cannot > tell what the intention of the sending backend was. That's why I > proposed to make SIGINT similar to SIGUSR1 where we write a reason to > a shared memory structure first and then send the signal (se

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-29 Thread Joachim Wieland
On Sun, Dec 27, 2009 at 10:42 PM, Simon Riggs wrote: > Thanks for the report. I'll see about a fix. In the end we are about to use SIGINT for two use cases: - cancel an idle transaction - cancel a running query Previously a backend that was DoingCommandRead == true didn't do anything upon rec

Re: [HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-27 Thread Simon Riggs
On Sat, 2009-12-26 at 20:15 -0500, Kris Jurka wrote: > The JDBC driver's regression test suite has revealed a change in behavior > introduced by the hot standy patch. Previously when a client sent a > cancel request on an idle connection, nothing happened. Now it sends an > error message "ERR

[HACKERS] Hot Standy introduced problem with query cancel behavior

2009-12-26 Thread Kris Jurka
The JDBC driver's regression test suite has revealed a change in behavior introduced by the hot standy patch. Previously when a client sent a cancel request on an idle connection, nothing happened. Now it sends an error message "ERROR: canceling statement due to user request". This confuse