On 12/8/13 3:08 PM, MauMau wrote:
#5 is output when the DBA shuts down the replication standby server.
#6 is output when the DBA shuts down the server if he is using any custom
background worker.
These messages are always output. What I'm seeing as a problem is that
FATAL messages are output
On 12/06/2013 03:02 AM, Josh Berkus wrote:
Heck, I'd be happy just to have a class of messages which specifically
means OMG, there's something wrong with the server, that is, a flag
for messages which only occur when PostgreSQL encounters a bug, data
corrpution, or platform error. Right now,
From: David Johnston pol...@yahoo.com
5. FATAL: terminating walreceiver process due to administrator command
6. FATAL: terminating background worker \%s\ due to administrator
command
5 and 6: I don't fully understand when they would happen but likely fall
into the same the DBA should know
From: David Johnston pol...@yahoo.com
5. FATAL: terminating walreceiver process due to administrator command
6. FATAL: terminating background worker \%s\ due to administrator
command
5 and 6: I don't fully understand when they would happen but likely fall
into the same the DBA should know
From: David Johnston pol...@yahoo.com
PITR/Failover is not generally that frequent an occurrence but I will
agree
that these events are likely common during such.
Maybe PITR/Failover mode can output something in the logs to alleviate
user
angst about these frequent events? I'm doubting that
From: Josh Berkus j...@agliodbs.com
Heck, I'd be happy just to have a class of messages which specifically
means OMG, there's something wrong with the server, that is, a flag
for messages which only occur when PostgreSQL encounters a bug, data
corrpution, or platform error. Right now, I have to
From: Alvaro Herrera alvhe...@2ndquadrant.com
There was also the idea that this would be driven off SQLSTATE but this
seems pretty unwieldy to me.
You are referring to this long discussion, don't you?
http://www.postgresql.org/message-id/19791.1335902...@sss.pgh.pa.us
I've read it before,
MauMau maumau...@gmail.com writes:
That discussion sounds interesting, and I want to take more time to
consider. But what do you think of my original suggestion to easily solve
the current issue? I'd like to remove the current annoying problem first
before spending much time for more
From: Tom Lane t...@sss.pgh.pa.us
There is no enthusiasm for a quick-hack solution here, and most people
don't actually agree with your proposal that these errors should never
get logged. So no, that is not happening. You can hack your local
copy that way if you like of course, but it's not
* David Johnston (pol...@yahoo.com) wrote:
ISTM that instituting some level of categorization for messages would be
helpful. Then logging and reporting frameworks would be able to identify
and segregate the logs in whatever way they and the configuration deems
appropriate.
I've wanted to do
On 12/05/2013 10:21 AM, Stephen Frost wrote:
* David Johnston (pol...@yahoo.com) wrote:
ISTM that instituting some level of categorization for messages would be
helpful. Then logging and reporting frameworks would be able to identify
and segregate the logs in whatever way they and the
Josh Berkus j...@agliodbs.com writes:
On 12/05/2013 10:21 AM, Stephen Frost wrote:
But ... if we set a firm policy on this, then we could gradually clean
up the error messages piecemeal over the next couple of major versions.
We could also make sure that any new features complied with the
On 12/05/2013 10:46 AM, Tom Lane wrote:
Before we could get very far we'd need a better understanding than we have
of what cases a DBA might be interested in. To take the specific example
that started this thread, there wouldn't be a lot of value IMO in a
classification like connection
Josh Berkus wrote:
Heck, I'd be happy just to have a class of messages which specifically
means OMG, there's something wrong with the server, that is, a flag
for messages which only occur when PostgreSQL encounters a bug, data
corrpution, or platform error. Right now, I have to suss those
14 matches
Mail list logo
