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

Re: syslogger line-end processing infelicity

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: syslogger line-end processing infelicity
Date: 2007-06-04 22:18:17
Message-ID: 46648FA9.7070409@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> 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 :-(
>
>
>   


I have been trying to think of how we can get around the problem of 
multiplexing our own output inappropriately. I have no great insights, 
but I did think of these:

. use one pipe per backend instead of one per postmaster, and have the 
syslogger poll them all.
. use a mutex to control access to the pipe
. same as previous but use a worker thread for each backend to do 
logging so blocking on the mutex wouldn't block the backend

All of these look like a lot of work for a relatively infrequent 
problem, not to mention plenty of other disadvantages.

cheers

andrew

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-06-04 23:06:43
Subject: Re: Implicit casts with generic arrays
Previous:From: Jim C. NasbyDate: 2007-06-04 21:18:03
Subject: Re: TOAST usage setting

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