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
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
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
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
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?
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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.
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
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
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
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
- 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
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
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
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
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
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
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
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
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
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:
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
49 matches
Mail list logo