What happens when syslog gets blocked?
We recently had a problem with a database where the /var filesystem
got corrupted. This appears to have seriously impacted the ability of
STDERR from Postgres to get put out to disk, which ended up blocking
backends.
Because of this we want to switch from using STDERR to using syslog,
but I'm not sure if syslog() can end up blocking or not. I know that
(by default) syslog uses UDP when logging to an external syslog, but
what happens if you're using the local syslog? Is it still UDP or
some other mechanism that could potentially block the backends?
Also, I think we should either warn users about STDERR (and
presumably the CVS logging) or change things so that something that
breaks logging doesn't block backends.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
decibel <decibel@decibel.org> writes:
We recently had a problem with a database where the /var filesystem
got corrupted. This appears to have seriously impacted the ability of
STDERR from Postgres to get put out to disk, which ended up blocking
backends.
Because of this we want to switch from using STDERR to using syslog,
but I'm not sure if syslog() can end up blocking or not.
syslog (at least in the implementations I'm familiar with) has the
opposite problem: when the going gets tough, it starts losing messages.
I do not think you'll really be making your life better by switching.
regards, tom lane
In response to Tom Lane <tgl@sss.pgh.pa.us>:
decibel <decibel@decibel.org> writes:
We recently had a problem with a database where the /var filesystem
got corrupted. This appears to have seriously impacted the ability of
STDERR from Postgres to get put out to disk, which ended up blocking
backends.Because of this we want to switch from using STDERR to using syslog,
but I'm not sure if syslog() can end up blocking or not.syslog (at least in the implementations I'm familiar with) has the
opposite problem: when the going gets tough, it starts losing messages.
I do not think you'll really be making your life better by switching.
Well ... "life better" really depends on which failure scenario you're
more comfortable with ... personally, I'd rather lose log messages than
have the DB system go down. Of course, if auditing is critical to your
scenario, then your priorities are different ...
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
On Aug 6, 2009, at 2:00 PM, Bill Moran wrote:
In response to Tom Lane <tgl@sss.pgh.pa.us>:
decibel <decibel@decibel.org> writes:
We recently had a problem with a database where the /var filesystem
got corrupted. This appears to have seriously impacted the
ability of
STDERR from Postgres to get put out to disk, which ended up blocking
backends.Because of this we want to switch from using STDERR to using syslog,
but I'm not sure if syslog() can end up blocking or not.syslog (at least in the implementations I'm familiar with) has the
opposite problem: when the going gets tough, it starts losing
messages.
I do not think you'll really be making your life better by switching.Well ... "life better" really depends on which failure scenario you're
more comfortable with ... personally, I'd rather lose log messages
than
have the DB system go down. Of course, if auditing is critical to
your
scenario, then your priorities are different ...
Bingo. I'm thinking we should make mention of this in the docs...
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
decibel wrote:
On Aug 6, 2009, at 2:00 PM, Bill Moran wrote:
Well ... "life better" really depends on which failure scenario you're
more comfortable with ... personally, I'd rather lose log messages
than
have the DB system go down. Of course, if auditing is critical to
your
scenario, then your priorities are different ...Bingo. I'm thinking we should make mention of this in the docs...
I propose the following patch.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Attachments:
collector-blocks.patchtext/x-diff; charset=us-asciiDownload+13-0
Alvaro Herrera wrote:
decibel wrote:
On Aug 6, 2009, at 2:00 PM, Bill Moran wrote:
Well ... "life better" really depends on which failure scenario you're
more comfortable with ... personally, I'd rather lose log messages
than
have the DB system go down. Of course, if auditing is critical to
your
scenario, then your priorities are different ...Bingo. I'm thinking we should make mention of this in the docs...
I propose the following patch.
Committed (on HEAD)
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support