On Thu, May 3, 2012 at 9:26 PM, Magnus Hagander mag...@hagander.net wrote:
On Thu, May 3, 2012 at 7:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Heh - we already used ERRCODE_CONNECTION_FAILURE on the errors in
copy.c. Since COPY can only happen when
Magnus Hagander mag...@hagander.net 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.
On Mon, May 7, 2012 at 5:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
On Mon, May 7, 2012 at 12:39 PM, Magnus Hagander mag...@hagander.net 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())
+
On Mon, May 7, 2012 at 7:18 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, May 7, 2012 at 12:39 PM, Magnus Hagander mag...@hagander.net 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
Magnus Hagander mag...@hagander.net writes:
On Mon, May 7, 2012 at 7:18 PM, Robert Haas robertmh...@gmail.com 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
On Thu, May 3, 2012 at 1:26 PM, Magnus Hagander mag...@hagander.net 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
On Thu, May 3, 2012 at 2:31 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, May 3, 2012 at 1:26 PM, Magnus Hagander mag...@hagander.net 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
On Thu, May 3, 2012 at 2:31 PM, Simon Riggs si...@2ndquadrant.com 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?
On Thu, May 3, 2012 at 2:34 PM, Vik Reykja vikrey...@gmail.com wrote:
On Thu, May 3, 2012 at 2:31 PM, Simon Riggs si...@2ndquadrant.com 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
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
Simon Riggs si...@2ndquadrant.com writes:
On Thu, May 3, 2012 at 1:26 PM, Magnus Hagander mag...@hagander.net 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
On Thu, May 3, 2012 at 2:46 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
On Thu, May 3, 2012 at 4:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Thu, May 3, 2012 at 1:26 PM, Magnus Hagander mag...@hagander.net wrote:
I had a request from a customer asking if we could make a switch to
specifically disable the unexpected EOF
Magnus Hagander mag...@hagander.net writes:
On Thu, May 3, 2012 at 4:17 PM, Tom Lane t...@sss.pgh.pa.us 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.)
On Thu, May 3, 2012 at 4:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, May 3, 2012 at 4:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I agree with Simon --- a disable for that specific message seems like a
kluge, and an ugly one at that. (The right
Magnus Hagander mag...@hagander.net writes:
On Thu, May 3, 2012 at 4:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Are you thinking basically regexp against the main text, or
something else, when you say generic filter capacity?
In the context of
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 t...@sss.pgh.pa.us 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.
On Thu, May 3, 2012 at 11:20 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
Robert Haas robertmh...@gmail.com writes:
On Thu, May 3, 2012 at 11:20 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Thu, May 3, 2012 at 11:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, May 3, 2012 at 11:20 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Hey, maybe we could add a UUID to each ereport() call site ;-)
I can't help but feel we're designing
Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Magnus Hagander's message:
Tom Lane t...@sss.pgh.pa.us 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
On Thu, May 3, 2012 at 11:46 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Magnus Hagander's message:
Tom Lane t...@sss.pgh.pa.us wrote:
In the context of yesterday's discussions, I wonder whether a
filter by SQLSTATE
Robert Haas robertmh...@gmail.com 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
On Thu, May 3, 2012 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, May 3, 2012 at 11:20 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Hey, maybe we could add a UUID to each ereport() call site ;-)
I can't help but feel we're designing
Magnus Hagander mag...@hagander.net writes:
On Thu, May 3, 2012 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
On Thu, May 3, 2012 at 7:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, May 3, 2012 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I could support that with one tweak: it's only DEBUG1 if you don't
have an open transaction. Dropping the
On Thu, May 3, 2012 at 7:21 PM, Magnus Hagander mag...@hagander.net wrote:
On Thu, May 3, 2012 at 7:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, May 3, 2012 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I could support that with one tweak: it's
Tom Lane t...@sss.pgh.pa.us 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
Magnus Hagander mag...@hagander.net 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
Kevin Grittner kevin.gritt...@wicourts.gov 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:
On Thu, May 3, 2012 at 7:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
34 matches
Mail list logo
