Magnus Hagander writes:
> On Mon, May 7, 2012 at 7:18 PM, Robert Haas wrote:
>> Since the following hunk is repeated 3x, maybe it should be stuffed
>> into a function that is then called in three places:
> I considered it trivial enough not to do that for it. I can perhaps be
> convinced otherwi
On Mon, May 7, 2012 at 7:18 PM, Robert Haas wrote:
> On Mon, May 7, 2012 at 12:39 PM, Magnus Hagander wrote:
>> Makes sense, will change and commit.
>
> Since the following hunk is repeated 3x, maybe it should be stuffed
> into a function that is then called in three places:
I considered it triv
On Mon, May 7, 2012 at 12:39 PM, Magnus Hagander wrote:
> Makes sense, will change and commit.
Since the following hunk is repeated 3x, maybe it should be stuffed
into a function that is then called in three places:
+ if (IsTransactionState())
+ ereport(COMMER
On Mon, May 7, 2012 at 5:15 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> Any further suggestoins for which codes to use? If not, I think I'm
>> going to commit the patch as I had it, because it's not any worse than
>> what we had before (but fixes the annoying messages), and we can
>> always
Magnus Hagander writes:
> Any further suggestoins for which codes to use? If not, I think I'm
> going to commit the patch as I had it, because it's not any worse than
> what we had before (but fixes the annoying messages), and we can
> always revisit the actual errorcodes later.
I'm still a bit u
On Thu, May 3, 2012 at 9:26 PM, Magnus Hagander wrote:
> On Thu, May 3, 2012 at 7:48 PM, Tom Lane wrote:
>> Magnus Hagander writes:
>>> Heh - we already used ERRCODE_CONNECTION_FAILURE on the errors in
>>> copy.c. Since COPY can only happen when there is a transaction
>>> (right?), I just change
On Thu, May 3, 2012 at 7:48 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> Heh - we already used ERRCODE_CONNECTION_FAILURE on the errors in
>> copy.c. Since COPY can only happen when there is a transaction
>> (right?), I just changed those error messages for consistency.
>
> Agreed on changing
"Kevin Grittner" writes:
> I still think it might be useful to differentiate in our server log
> between the case where the transaction failed and the case where the
> transaction committed but we don't know that the client got the news
> of that. How about something like:
> 2DP01 connection_l
Magnus Hagander writes:
> Heh - we already used ERRCODE_CONNECTION_FAILURE on the errors in
> copy.c. Since COPY can only happen when there is a transaction
> (right?), I just changed those error messages for consistency.
Agreed on changing the message texts to match, but I wonder whether
we ough
Tom Lane wrote:
> AFAICS, all the 08 class is meant to be issued by client-side
> code, not the server. I think we probably have to use nonstandard
> SQLSTATEs for these messages.
OK, if we're going that route, how about using "Class 2D * Invalid
Transaction Termination"?
I still think it m
On Thu, May 3, 2012 at 7:21 PM, Magnus Hagander wrote:
> On Thu, May 3, 2012 at 7:09 PM, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Thu, May 3, 2012 at 5:39 PM, Tom Lane wrote:
I could support that with one tweak: it's only DEBUG1 if you don't
have an open transaction. Droppin
On Thu, May 3, 2012 at 7:09 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, May 3, 2012 at 5:39 PM, Tom Lane wrote:
>>> I could support that with one tweak: it's only DEBUG1 if you don't
>>> have an open transaction. Dropping the connection while in a
>>> transaction *is* an applicatio
"Kevin Grittner" writes:
> Would it make sense to use 08003 (connection_does_not_exist) when a
> broken connection for an idle process is discovered, and 08006
> (connection_failure) for the "in transaction" failure? What about a
> failure just after COMMIT and before successfully sending that
>
Tom Lane wrote:
> Robert Haas writes:
>> Well, nearby Tom and I discussed demoting the message to DEBUG1
>> when no transaction is in progress. Presumably the two messages
>> would share the same SQL state, unless we're going to create
>> separate SQL states for connection-closed-not-in-a-txn an
Magnus Hagander writes:
> On Thu, May 3, 2012 at 5:39 PM, Tom Lane wrote:
>> I could support that with one tweak: it's only DEBUG1 if you don't
>> have an open transaction. Dropping the connection while in a
>> transaction *is* an application bug; I don't care how lazy the app
>> programmer is f
On Thu, May 3, 2012 at 5:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, May 3, 2012 at 11:20 AM, Alvaro Herrera
>> wrote:
>>> Hey, maybe we could add a UUID to each ereport() call site ;-)
>
>> I can't help but feel we're designing a $10.00 solution to a $0.25
>> problem. I think I'd a
Robert Haas writes:
> Well, nearby Tom and I discussed demoting the message to DEBUG1 when
> no transaction is in progress. Presumably the two messages would
> share the same SQL state, unless we're going to create separate SQL
> states for connection-closed-not-in-a-txn and
> connection-closed-i
On Thu, May 3, 2012 at 11:46 AM, Kevin Grittner
wrote:
> Alvaro Herrera wrote:
>> Excerpts from Magnus Hagander's message:
>>> Tom Lane wrote:
In the context of yesterday's discussions, I wonder whether a
filter by SQLSTATE would be appropriate.
>>>
>>> I'm worried it's not really gran
Alvaro Herrera wrote:
> Excerpts from Magnus Hagander's message:
>> Tom Lane wrote:
>>> In the context of yesterday's discussions, I wonder whether a
>>> filter by SQLSTATE would be appropriate.
>>
>> I'm worried it's not really granular enough.
>
> Yeah.
Just to be sure we're not inventing a
On Thu, May 3, 2012 at 11:39 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, May 3, 2012 at 11:20 AM, Alvaro Herrera
>> wrote:
>>> Hey, maybe we could add a UUID to each ereport() call site ;-)
>
>> I can't help but feel we're designing a $10.00 solution to a $0.25
>> problem. I think I'd
Robert Haas writes:
> On Thu, May 3, 2012 at 11:20 AM, Alvaro Herrera
> wrote:
>> Hey, maybe we could add a UUID to each ereport() call site ;-)
> I can't help but feel we're designing a $10.00 solution to a $0.25
> problem. I think I'd actually support adding something like a UUID to
> every e
On Thu, May 3, 2012 at 11:20 AM, Alvaro Herrera
wrote:
> Hey, maybe we could add a UUID to each ereport() call site ;-)
I can't help but feel we're designing a $10.00 solution to a $0.25
problem. I think I'd actually support adding something like a UUID to
every ereport and a filtering mechanism
Excerpts from Magnus Hagander's message of jue may 03 10:58:12 -0400 2012:
> On Thu, May 3, 2012 at 4:53 PM, Tom Lane wrote:
> > In the context of yesterday's discussions, I wonder whether a filter by
> > SQLSTATE would be appropriate.
>
> I'm worried it's not really granular enough.
Yeah.
> r
Magnus Hagander writes:
> On Thu, May 3, 2012 at 4:53 PM, Tom Lane wrote:
>> Magnus Hagander writes:
>>> Are you thinking basically "regexp against the main text", or
>>> something else, when you say "generic filter capacity"?
>> In the context of yesterday's discussions, I wonder whether a fil
On Thu, May 3, 2012 at 4:53 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, May 3, 2012 at 4:17 PM, Tom Lane wrote:
>>> I agree with Simon --- a disable for that specific message seems like a
>>> kluge, and an ugly one at that. (The right solution for this customer
>>> is to fix their
Magnus Hagander writes:
> On Thu, May 3, 2012 at 4:17 PM, Tom Lane wrote:
>> I agree with Simon --- a disable for that specific message seems like a
>> kluge, and an ugly one at that. (The right solution for this customer
>> is to fix their broken application.) But a generic filter capability
>
On Thu, May 3, 2012 at 4:17 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Thu, May 3, 2012 at 1:26 PM, Magnus Hagander wrote:
>>> I had a request from a customer asking if we could make a switch to
>>> specifically disable the "unexpected EOF" message that fills lots of
>>> peoples logs.
>
>>
On Thu, May 3, 2012 at 2:46 PM, Kevin Grittner
wrote:
> Magnus Hagander wrote:
>
>> Also, AFAIK we don't *have* a "message type" at this point (one of
>> the things said mythical project wanted to look at), so the only
>> thing we could really filter on would be the whole text of the
>> message,
Simon Riggs writes:
> On Thu, May 3, 2012 at 1:26 PM, Magnus Hagander wrote:
>> I had a request from a customer asking if we could make a switch to
>> specifically disable the "unexpected EOF" message that fills lots of
>> peoples logs.
> Yes, if the new parameter allows a generic filter on mult
Magnus Hagander wrote:
> Also, AFAIK we don't *have* a "message type" at this point (one of
> the things said mythical project wanted to look at), so the only
> thing we could really filter on would be the whole text of the
> message, no?
We have SQLSTATE, but this seems to be one of those sit
On Thu, May 3, 2012 at 2:34 PM, Vik Reykja wrote:
> On Thu, May 3, 2012 at 2:31 PM, Simon Riggs wrote:
>>
>> > Would we consider adding such a switch (it should be easy enough to
>> > do), or do we want to push this off to the mythical "let's improve the
>> > logging subsystem" project that might
On Thu, May 3, 2012 at 2:31 PM, Simon Riggs wrote:
> > Would we consider adding such a switch (it should be easy enough to
> > do), or do we want to push this off to the mythical "let's improve the
> > logging subsystem" project that might eventually materialize if we're
> > lucky? Meaning - woul
On Thu, May 3, 2012 at 2:31 PM, Simon Riggs wrote:
> On Thu, May 3, 2012 at 1:26 PM, Magnus Hagander wrote:
>> I had a request from a customer asking if we could make a switch to
>> specifically disable the "unexpected EOF" message that fills lots of
>> peoples logs. Along the same way that we ha
On Thu, May 3, 2012 at 1:26 PM, Magnus Hagander wrote:
> I had a request from a customer asking if we could make a switch to
> specifically disable the "unexpected EOF" message that fills lots of
> peoples logs. Along the same way that we have a flag to turn off the
> "nonstandard use of string es
I had a request from a customer asking if we could make a switch to
specifically disable the "unexpected EOF" message that fills lots of
peoples logs. Along the same way that we have a flag to turn off the
"nonstandard use of string escapes" message that is another culprit
(that's actually a much *
35 matches
Mail list logo
