Thread: more robust log rotation

more robust log rotation

From
Andrew Dunstan
Date:
I have been trying to come up with a simple plan to make log rotation 
more robust, particularly in not splitting log lines across files. Greg 
Smith complained that lines could be split if logs are rotated on size, 
but AFAICS the danger also exists for time based rotation.

My thought is to have the logger mark each true log line line end with a 
null byte. The syslogger would have a state variable called, say, 
safe_to_rotate, which would be set true if and only if the last thing 
written to the log file was a "\n"  from the input stream which was 
followed by a null byte. The null bytes would of course never actually 
be sent to the files. Log rotation would be delayed until variable this 
was set true.

There is a small danger that the delay in log rotation might be 
substantial - with a series of partial lines read. I suspect that in 
practice this danger would be vanishingly small, and we might reasonably 
expect that the condition would come true within a few cycles.

An alternative scheme would involve keeping some extra buffer(s) of data 
so that we ensure we never write out a partial line to the file. But 
that seems to me to involve a lot more processing and so I'm wary of it.

I don't think we should contemplate providing for CSV logs until we have 
this problem solved, so it's rather important.

Thoughts?

cheers

andrew


Re: more robust log rotation

From
Tom Lane
Date:
Andrew Dunstan <andrew@dunslane.net> writes:
> My thought is to have the logger mark each true log line line end with a 
> null byte.

This seems not to help much when you consider interleaved output from
different backends...
        regards, tom lane


Re: more robust log rotation

From
Andrew Dunstan
Date:

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> My thought is to have the logger mark each true log line line end with a 
>> null byte.
>>     
>
> This seems not to help much when you consider interleaved output from
> different backends...
>
>             
>   

True. We have two problems with log robustness, and this was an attempt 
to address one of them. I sent some thoughts about interleaving 
yesterday. If you have any thoughts about handling interleaving then I'm 
all ears. However, my impression was that this only happened on a small 
number of platforms. If it's more general then it's all the more urgent 
to fix. ISTM that we can't really consider CSV logging until we have a 
handle on both problems.

cheers

andrew