On Mon, Feb 7, 2011 at 4:11 PM, Simon Riggs wrote:
>> So I guess the only remaining issue is whether we should distinguish
>> the error message text, as well as the error codes. Tom was in favor
>> of that upthread, and I am too. Right now we have:
> The error text is already differentiated by
>
On Wed, 2011-02-02 at 21:21 -0500, Robert Haas wrote:
> On Tue, Feb 1, 2011 at 3:17 AM, Simon Riggs wrote:
> > ERRCODE_DATABASE_DROPPED57P04 looks best
>
> So I guess the only remaining issue is whether we should distinguish
> the error message text, as well as the error codes. Tom was in
On Tue, Feb 1, 2011 at 3:17 AM, Simon Riggs wrote:
> ERRCODE_DATABASE_DROPPED 57P04 looks best
So I guess the only remaining issue is whether we should distinguish
the error message text, as well as the error codes. Tom was in favor
of that upthread, and I am too. Right now we have:
On Tue, 2011-02-01 at 11:43 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > Here's the basic patch, will work on the refactoring if no objections.
>
> ResolveRecoveryConflictWithDatabase works when you're not in recovery?
> That seems pretty fragile at best. In any case, this is a 9.2 feature
>
Simon Riggs writes:
> Here's the basic patch, will work on the refactoring if no objections.
ResolveRecoveryConflictWithDatabase works when you're not in recovery?
That seems pretty fragile at best. In any case, this is a 9.2 feature
at the earliest, please do not expect people to spend time on
On Tue, 2011-02-01 at 07:35 +0100, Magnus Hagander wrote:
> On Tue, Feb 1, 2011 at 03:29, Robert Haas wrote:
> > On Mon, Jan 31, 2011 at 8:52 PM, Tom Lane wrote:
> >>> Then again - in theory, there's no reason why we couldn't drop a
> >>> database on the master when it's in use, kicking out every
On Mon, 2011-01-31 at 20:52 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jan 31, 2011 at 7:25 PM, Tom Lane wrote:
> >> Robert Haas writes:
> >>> Seems a little weird to me, since the administrator hasn't done
> >>> anything.
>
> >> Sure he has: he issued the DROP DATABASE command th
On Mon, 2011-01-31 at 20:27 -0500, Robert Haas wrote:
> So I don't see why one particular kind of recovery conflict
> should be in a different class than all the others.
This point has been explained many times and is very clear in the code.
It has a clear functional purpose, not decoration or m
On Tue, Feb 1, 2011 at 03:29, Robert Haas wrote:
> On Mon, Jan 31, 2011 at 8:52 PM, Tom Lane wrote:
>>> Then again - in theory, there's no reason why we couldn't drop a
>>> database on the master when it's in use, kicking out everyone using it
>>> with this very same error code. We don't happen
On Mon, Jan 31, 2011 at 8:52 PM, Tom Lane wrote:
>> Then again - in theory, there's no reason why we couldn't drop a
>> database on the master when it's in use, kicking out everyone using it
>> with this very same error code. We don't happen to handle it that way
>> right now, but...
>
> Yeah, th
Robert Haas writes:
> On Mon, Jan 31, 2011 at 7:25 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Seems a little weird to me, since the administrator hasn't done
>>> anything.
>> Sure he has: he issued the DROP DATABASE command that's causing the
>> system to disconnect standby sessions.
> Wel
On Mon, Jan 31, 2011 at 7:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 31, 2011 at 7:12 PM, Tom Lane wrote:
>>> I agree, 28 is a completely off-point category. But it wasn't in 40
>>> before, either --- we are talking about where it currently says
>>> ADMIN_SHUTDOWN, no? I'd vot
Simon Riggs writes:
> BTW, anybody know why we have PL/pgSQL condition codes for conditions
> that can't be trapped by PL/pgSQL? ERRCODE_ADMIN_SHUTDOWN and
> ERRCODE_DATABASE_DROPPED are always FATAL. Seems like pointless code to
> me.
There's a difference between not being able to trap the error
On Mon, 2011-01-31 at 19:12 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs wrote:
> >> I would make ERRCODE_DATABASE_DROPPED an Invalid Authorization error,
> >> rather than a Transaction Rollback code. So sqlstate 28P02
>
> > ISTM it should still b
Robert Haas writes:
> On Mon, Jan 31, 2011 at 7:12 PM, Tom Lane wrote:
>> I agree, 28 is a completely off-point category. But it wasn't in 40
>> before, either --- we are talking about where it currently says
>> ADMIN_SHUTDOWN, no? I'd vote for keeping it in class 57 (operator
>> intervention),
On Mon, Jan 31, 2011 at 7:13 PM, Josh Berkus wrote:
>> BTW, anybody know why we have PL/pgSQL condition codes for conditions
>> that can't be trapped by PL/pgSQL? ERRCODE_ADMIN_SHUTDOWN and
>> ERRCODE_DATABASE_DROPPED are always FATAL. Seems like pointless code to
>> me.
>
> So we can support auto
On Mon, Jan 31, 2011 at 7:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs wrote:
>>> I would make ERRCODE_DATABASE_DROPPED an Invalid Authorization error,
>>> rather than a Transaction Rollback code. So sqlstate 28P02
>
>> ISTM it should still be in c
> BTW, anybody know why we have PL/pgSQL condition codes for conditions
> that can't be trapped by PL/pgSQL? ERRCODE_ADMIN_SHUTDOWN and
> ERRCODE_DATABASE_DROPPED are always FATAL. Seems like pointless code to
> me.
So we can support autonomous transactions in the future?
--
Robert Haas writes:
> On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs wrote:
>> I would make ERRCODE_DATABASE_DROPPED an Invalid Authorization error,
>> rather than a Transaction Rollback code. So sqlstate 28P02
> ISTM it should still be in class 40. There's nothing wrong with the
> user's authori
On Mon, 2011-01-31 at 18:21 -0500, Robert Haas wrote:
> > Ready to commit if no objection.
>
> ISTM it should still be in class 40. There's nothing wrong with the
> user's authorization; we've just decided to roll back the transaction
> for our own purposes.
OK.
BTW, anybody know why we have PL
On Mon, Jan 31, 2011 at 6:07 PM, Simon Riggs wrote:
> On Mon, 2011-01-31 at 16:24 -0500, Tom Lane wrote:
>> Simon Riggs writes:
>> > On Mon, 2011-01-31 at 14:58 -0500, Tom Lane wrote:
>> >> The trouble with ERRCODE_ADMIN_SHUTDOWN is that it might lead a
>> >> connection pooler to expect that *all
On Mon, 2011-01-31 at 16:24 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2011-01-31 at 14:58 -0500, Tom Lane wrote:
> >> The trouble with ERRCODE_ADMIN_SHUTDOWN is that it might lead a
> >> connection pooler to expect that *all* its connections are going bad,
> >> not just the ones tha
On 1/31/11 11:26 AM, Simon Riggs wrote:
> The purpose of errcodes is to allow programs to check them and then act.
> It's pointless to add a new errcode that is so rare that nobody will
> ever program for it because they won't expect it, let alone test for it.
> Or at least won't assign any sensibl
Simon Riggs writes:
> On Mon, 2011-01-31 at 14:58 -0500, Tom Lane wrote:
>> The trouble with ERRCODE_ADMIN_SHUTDOWN is that it might lead a
>> connection pooler to expect that *all* its connections are going bad,
>> not just the ones that are connected to a specific database. I think
>> this is a
On Mon, 2011-01-31 at 14:58 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2011-01-31 at 11:24 -0500, Robert Haas wrote:
> >> , or to use a new
> >> error code. ERRCODE_ADMIN_SHUTDOWN is just strange.
>
> > It's not strange at all. It's the same error code as we use for all of
> > the
Simon Riggs writes:
> On Mon, 2011-01-31 at 11:24 -0500, Robert Haas wrote:
>> , or to use a new
>> error code. ERRCODE_ADMIN_SHUTDOWN is just strange.
> It's not strange at all. It's the same error code as we use for all of
> the other cases listed. We need that because it is the current
> catc
On Mon, 2011-01-31 at 11:24 -0500, Robert Haas wrote:
> On Mon, Jan 31, 2011 at 10:31 AM, Kevin Grittner
> wrote:
> > Bruce Momjian wrote:
> >> As a novice I am not sure why we _wouldn't_ create two new
> >> separate error codes
> >
> > The argument for using SQLSTATE 40001 for failures which are
On Mon, Jan 31, 2011 at 10:31 AM, Kevin Grittner
wrote:
> Bruce Momjian wrote:
>> As a novice I am not sure why we _wouldn't_ create two new
>> separate error codes
>
> The argument for using SQLSTATE 40001 for failures which are
> strictly due to concurrency problems, and are likely to work if t
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > As a novice I am not sure why we _wouldn't_ create two new
> > separate error codes
>
> The argument for using SQLSTATE 40001 for failures which are
> strictly due to concurrency problems, and are likely to work if the
> transaction is retried
On Mon, 2011-01-31 at 09:46 -0500, Bruce Momjian wrote:
> > Actually, it was Simon and Florian who were arguing that we needed to
> > distinguish these cases from other types of recovery conflict;
> > Tatsuo-san was arguing that we needed to distinguish a
> > dropped-database-recovery-conflict from
Bruce Momjian wrote:
> As a novice I am not sure why we _wouldn't_ create two new
> separate error codes
The argument for using SQLSTATE 40001 for failures which are
strictly due to concurrency problems, and are likely to work if the
transaction is retried, is that there is already a lot of so
> Actually, it was Simon and Florian who were arguing that we needed to
> distinguish these cases from other types of recovery conflict;
> Tatsuo-san was arguing that we needed to distinguish a
> dropped-database-recovery-conflict from a cluster shutdown - the
> current choice of ERRCODE_ADMIN_SHUT
On Sun, Jan 30, 2011 at 9:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jan 30, 2011 at 8:42 PM, Tom Lane wrote:
>>> BTW, so far as this goes:
>>> http://archives.postgresql.org/pgsql-hackers/2011-01/msg01152.php
>>> we should certainly *not* have the same text for two different
>>> SQ
Robert Haas writes:
> On Sun, Jan 30, 2011 at 8:42 PM, Tom Lane wrote:
>> BTW, so far as this goes:
>> http://archives.postgresql.org/pgsql-hackers/2011-01/msg01152.php
>> we should certainly *not* have the same text for two different
>> SQLSTATEs. If it's worth distinguishing two cases then it'
On Sun, Jan 30, 2011 at 8:42 PM, Tom Lane wrote:
>> Any opinion on what to do about the one that's returning
>> ERRCODE_ADMIN_SHUTDOWN?
>
> Pretty much the same argument here, I think: if we are going to change
> the SQLSTATE we should do it now not later. However, I think Simon
> was actually a
Robert Haas writes:
> On Sun, Jan 30, 2011 at 8:11 PM, Tom Lane wrote:
>> I'm inclined to agree that 9.0 is new enough that changing this
>> shouldn't be too traumatic. If we leave it till 9.1 there will
>> probably be more pain not less.
> But if you and Tatsuo-san are both in favor of it, the
On Sun, Jan 30, 2011 at 8:11 PM, Tom Lane wrote:
> Tatsuo Ishii writes:
>> On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas wrote:
>>> It seems like we have consensus to change
>>> CheckRecoveryConflictDetected() to return
>>> ERRCODE_T_R_DEADLOCK_DETECTED in 9.1, but not on whether to also
>>> chan
Tatsuo Ishii writes:
> On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas wrote:
>> It seems like we have consensus to change
>> CheckRecoveryConflictDetected() to return
>> ERRCODE_T_R_DEADLOCK_DETECTED in 9.1, but not on whether to also
>> change that in 9.0 (votes: Robert - for, Simon - against)
>
Robert,
> On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas wrote:
>> On Fri, Jan 21, 2011 at 7:48 AM, Simon Riggs wrote:
>>> Ah, thanks Florian. Now I understand. There are two related issues here.
>>>
>>> 1. The discussion around ERRCODE_ADMIN_SHUTDOWN is incorrect and the
>>> specific patch should
On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas wrote:
> On Fri, Jan 21, 2011 at 7:48 AM, Simon Riggs wrote:
>> Ah, thanks Florian. Now I understand. There are two related issues here.
>>
>> 1. The discussion around ERRCODE_ADMIN_SHUTDOWN is incorrect and the
>> specific patch should be rejected as
On Fri, Jan 21, 2011 at 7:48 AM, Simon Riggs wrote:
> Ah, thanks Florian. Now I understand. There are two related issues here.
>
> 1. The discussion around ERRCODE_ADMIN_SHUTDOWN is incorrect and the
> specific patch should be rejected as is. No changes are required in
> ProcessInterrupts(), nor n
On Fri, 2011-01-21 at 13:09 +0100, Florian Pflug wrote:
> >
> >>> I'd also be in favor of changing the one that uses
> >>> ERRCODE_QUERY_CANCELLED to use ERRCODE_T_R_SERIALIZATION_FAILURE, as
> >>> the former might be taken to imply active user intervention, and for
> >>> consistency.
> >>
> >> +
On Jan21, 2011, at 10:16 , Simon Riggs wrote:
> On Fri, 2011-01-21 at 13:49 +0900, Tatsuo Ishii wrote:
>>
>>> I'm pretty well convinced that we should NOT be issuing
>>> ERRCODE_ADMIN_SHUTDOWN for a recovery conflict, but that could be
>>> fixed by a trivial simplification of the code posted above
On Fri, 2011-01-21 at 13:49 +0900, Tatsuo Ishii wrote:
> >
> > I'm pretty well convinced that we should NOT be issuing
> > ERRCODE_ADMIN_SHUTDOWN for a recovery conflict, but that could be
> > fixed by a trivial simplification of the code posted above, without
> > introducing any new error code.
>
> On Fri, Jan 14, 2011 at 1:51 PM, Robert Haas wrote:
>> On Fri, Jan 14, 2011 at 12:29 PM, Simon Riggs wrote:
>>> This whole thing is confused. No change is appropriate here at all.
>>>
>>> We issue ERRCODE_T_R_SERIALIZATION_FAILURE almost all of the time for
>>> recovery conflicts.
>>>
>>> We is
On Fri, Jan 14, 2011 at 1:51 PM, Robert Haas wrote:
> On Fri, Jan 14, 2011 at 12:29 PM, Simon Riggs wrote:
>> This whole thing is confused. No change is appropriate here at all.
>>
>> We issue ERRCODE_T_R_SERIALIZATION_FAILURE almost all of the time for
>> recovery conflicts.
>>
>> We issue ERRCO
On Fri, Jan 14, 2011 at 12:29 PM, Simon Riggs wrote:
> This whole thing is confused. No change is appropriate here at all.
>
> We issue ERRCODE_T_R_SERIALIZATION_FAILURE almost all of the time for
> recovery conflicts.
>
> We issue ERRCODE_ADMIN_SHUTDOWN only if the conflict is non-retryable,
> wh
On Fri, 2011-01-14 at 12:04 -0500, Tom Lane wrote:
> Tatsuo Ishii writes:
> >> Review:
> >> The only possible point of concern I see here is the naming of the C
> >> identifier. Everything else in class 40 uses ERRCODE_T_R_whatever,
> >> with T_R standing for transaction rollback. It's not obvio
Tatsuo Ishii writes:
>> Review:
>> The only possible point of concern I see here is the naming of the C
>> identifier. Everything else in class 40 uses ERRCODE_T_R_whatever,
>> with T_R standing for transaction rollback. It's not obvious to me
>> that that convention has any real value, but perh
On Fri, Jan 14, 2011 at 10:53 AM, Tatsuo Ishii wrote:
>> Review:
>>
>> The only possible point of concern I see here is the naming of the C
>> identifier. Everything else in class 40 uses ERRCODE_T_R_whatever,
>> with T_R standing for transaction rollback. It's not obvious to me
>> that that con
> Review:
>
> The only possible point of concern I see here is the naming of the C
> identifier. Everything else in class 40 uses ERRCODE_T_R_whatever,
> with T_R standing for transaction rollback. It's not obvious to me
> that that convention has any real value, but perhaps we ought to
> follow
On Thu, Jan 13, 2011 at 7:31 PM, Tatsuo Ishii wrote:
>> Tatsuo Ishii writes:
Please add this to the currently open CommitFest:
https://commitfest.postgresql.org/action/commitfest_view/open
>>
>>> Done. Comments are welcome. Unless there's objection, I will commit it
>>> this weekend.
>>
> Tatsuo Ishii writes:
>>> Please add this to the currently open CommitFest:
>>> https://commitfest.postgresql.org/action/commitfest_view/open
>
>> Done. Comments are welcome. Unless there's objection, I will commit it
>> this weekend.
>
> If you're expecting anyone to actually *review* it durin
Tatsuo Ishii writes:
>> Please add this to the currently open CommitFest:
>> https://commitfest.postgresql.org/action/commitfest_view/open
> Done. Comments are welcome. Unless there's objection, I will commit it
> this weekend.
If you're expecting anyone to actually *review* it during the CF,
th
> On Thu, Jan 13, 2011 at 2:13 AM, Tatsuo Ishii wrote:
>> Ok. Here is the patch for this. I use 40P02, instead of 40004.
>
> Please add this to the currently open CommitFest:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
Done. Comments are welcome. Unless there's objection,
On Thu, Jan 13, 2011 at 2:13 AM, Tatsuo Ishii wrote:
> Ok. Here is the patch for this. I use 40P02, instead of 40004.
Please add this to the currently open CommitFest:
https://commitfest.postgresql.org/action/commitfest_view/open
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Ent
>>> That doesn't sound right to me. I'd have thought something in class 40.
>>
>> What about:
>>
>> 40004 CONFLICT WITH RECOVERY conflict_with_recovery
>
> We should respect the following convention, from errcodes.h:
>
> * The convention is that new error codes defined by PostgreSQL in a
> * c
On Tue, Jan 11, 2011 at 1:30 AM, Tatsuo Ishii wrote:
>> On Sat, Jan 8, 2011 at 9:52 AM, Tatsuo Ishii wrote:
>>> While looking at the backend code, I realized that error code for
>>> "terminating connection due to conflict with recovery" is
>>> ERRCODE_ADMIN_SHUTDOWN.
>>>
>>> I thought the error c
> On Sat, Jan 8, 2011 at 9:52 AM, Tatsuo Ishii wrote:
>> While looking at the backend code, I realized that error code for
>> "terminating connection due to conflict with recovery" is
>> ERRCODE_ADMIN_SHUTDOWN.
>>
>> I thought the error code is for somewhat a human interruption, such as
>> shutdow
On Sat, Jan 8, 2011 at 9:52 AM, Tatsuo Ishii wrote:
> While looking at the backend code, I realized that error code for
> "terminating connection due to conflict with recovery" is
> ERRCODE_ADMIN_SHUTDOWN.
>
> I thought the error code is for somewhat a human interruption, such as
> shutdown comman
While looking at the backend code, I realized that error code for
"terminating connection due to conflict with recovery" is
ERRCODE_ADMIN_SHUTDOWN.
I thought the error code is for somewhat a human interruption, such as
shutdown command issued by pg_ctl. Is the usage of the error code
appropreate?
61 matches
Mail list logo
