Skip site navigation (1) Skip section navigation (2)

Re: syslogger line-end processing infelicity

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: syslogger line-end processing infelicity
Date: 2007-06-01 22:30:10
Message-ID: 24952.1180737010@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> +1 on that.  The problem of ensuring atomic output remains though
>> (see nearby complaints from George Pavlov and others).

> Is that the one you suggested trying to fix by calling write() instead 
> of fprintf()? If so, I can't think of any good reason not to do that 
> anyway.

Probably not, but it doesn't fix the problem for long log lines (more
than PIPE_BUF bytes).

The other little problem (which is the reason we like the stderr
approach in the first place) is that not all the stderr output we want
to capture comes from code under our control.  This may not be a huge
problem in production situations, since the main issue in my experience
is being able to capture dynamic-linker messages when shlib loading fails.
But it is a stumbling block in the way of any proposals that involve
having a more structured protocol for the stuff going down the wire :-(

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Jim NasbyDate: 2007-06-01 22:53:56
Subject: Re: [HACKERS] table partitioning pl/pgsql helpers
Previous:From: Tom LaneDate: 2007-06-01 22:25:13
Subject: Re: query log corrupted-looking entries

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group