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 letting

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 Freundand...@anarazel.de writes: I did not want to suggest using Simons code there. Sorry for the brevity. should have read as

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 Freundand...@anarazel.de writes: I did not want to suggest using Simons code there. Sorry for

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 client

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

2010-01-12 Thread Tom Lane
Andres Freund and...@anarazel.de 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?

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 and...@anarazel.de writes:

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 adding a

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 Freundand...@anarazel.de 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

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 Freundand...@anarazel.de 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

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 si...@2ndquadrant.com 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

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 si...@2ndquadrant.com 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

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 si...@2ndquadrant.com 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

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

2010-01-07 Thread Tom Lane
Joachim Wieland j...@mcknight.de 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

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 t...@sss.pgh.pa.us wrote: Joachim Wieland j...@mcknight.de 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

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 si...@2ndquadrant.com 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

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 si...@2ndquadrant.com 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

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

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

2010-01-07 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com 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

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 si...@2ndquadrant.com 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

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

2010-01-07 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com 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

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 si...@2ndquadrant.com 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

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

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

2010-01-07 Thread Tom Lane
Andres Freund and...@anarazel.de 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

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 transaction

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 t...@sss.pgh.pa.us 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

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

2010-01-07 Thread Tom Lane
Joachim Wieland j...@mcknight.de writes: On Thu, Jan 7, 2010 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us 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

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 and...@anarazel.de 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

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

2010-01-07 Thread Tom Lane
Andres Freund and...@anarazel.de 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

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 and...@anarazel.de 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

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

2010-01-07 Thread Tom Lane
Andres Freund and...@anarazel.de 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

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 and...@anarazel.de 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

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 that the

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: procsignal.c:

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 fairly small. i.e.

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 t...@sss.pgh.pa.us 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

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 t...@sss.pgh.pa.us 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

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 and...@anarazel.de 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

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 and...@anarazel.de 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 and...@anarazel.de writes: On Tuesday 29 December 2009 16:22:54 Tom Lane wrote: This seems

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 and...@anarazel.de 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 and...@anarazel.de writes: On Tuesday 29 December

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 and...@anarazel.de wrote: - Ursprüngliche Mitteilung - On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund and...@anarazel.de wrote: On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote: On Tue, 2009-12-29 at 11:13 -0500, Tom Lane

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 and...@anarazel.de wrote: On Wed, Dec 30, 2009 at 2:06 PM, Andres Freund and...@anarazel.de wrote: On Wednesday 30 December 2009 01:13:01 Simon Riggs wrote: On Tue, 2009-12-29 at

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 si...@2ndquadrant.com 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

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

2009-12-29 Thread Tom Lane
Joachim Wieland j...@mcknight.de 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

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 j...@mcknight.de 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

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

2009-12-29 Thread Tom Lane
Andres Freund and...@anarazel.de 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

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

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 and...@anarazel.de 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

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 ERROR:

[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 confuses