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
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
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
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
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
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
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
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)".
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)".
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
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
>
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
> >
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
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
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
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
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
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_
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
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
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
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
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
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
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...
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
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
>
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
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
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
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
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
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
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
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:
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
- 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
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.
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
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
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
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
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
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
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
>
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
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
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
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
49 matches
Mail list logo
