Thread: 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.
Attachment
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