Re: log_filename_prefix --> log_filename + strftime()

From: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Subject: Re: log_filename_prefix --> log_filename + strftime()
Date: 2004-09-20 23:25:20
Message-ID: 200409201725.20807.pgsql@bluepolka.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Monday September 20 2004 4:57, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> > Consider the case if one is
> > truncating logs on rotation and rotating hourly. UTC vs local is
> > irrelevant. If local time shifts backward from 02:00 to 01:00, our UTC
> > offset will move in the negative direction. If 1) our policy were to
> > truncate on rotation, and 2) we were rotating hourly or more
> > frequently, and 3) our filename would be identical the 2nd time through
> > that clock hour (i.e., it did not contain the epoch or UTC offset),
> > this could cause a log file rotation into the same filename we just had
> > open, thereby erasing an hour of log data. Apache's rotatelogs
> > apparently has the same issue without a solution, and warns of it in
> > the code.
>
> Hmm. Maybe we should remember the previous filename, and only truncate
> when the new one is different (plus all the other conditions); else
> append.

Sounds good. If you accept that the DST gotcha already exists and this
patch is independent of it, would you consider applying this patch
regardless? I'd be happy to submit an addition for your idea as my time
permits.

Ed

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-09-20 23:39:59 Re: log_filename_prefix --> log_filename + strftime()
Previous Message Tom Lane 2004-09-20 23:23:16 Re: [SQL] COUNT(*) to find records which have a certain number of dependencies ?