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-08-31 05:07:24 |
Message-ID: | 200408302307.24747.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Monday August 30 2004 10:56, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> >
> > Attached is a revised patch:
>
> Applied with minor revisions.
>
> > I did not add UTC offset logic nor logic to shift to top of the
> > hour/day for rotation periods of 60/1440 minutes, but would like to add
> > that shortly if time permits.
>
> I did the latter but not the former -- ie, rotation target times are
> rounded off, but rounded with respect to GMT not local time. I didn't
> see an obviously correct behavior of round-to-local-time across DST
> transitions ...
One idea for handling the round-to-localtime issue from the other end of the
problem: optionally rotate logs upon an *interpolated* filename change.
Then, 'server_log.%a' would cause a rotation when strftime() thinks it's
midnight local, 'server_log.%H' would rotate at the top of the hour, etc.
Possibly a half-baked idea.
I also noticed pg_tm.tm_gmtoff is apparently not set, at least not for my
local (US MT).
Ed
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-31 05:19:36 | Re: log_filename_prefix --> log_filename + strftime() |
Previous Message | Tom Lane | 2004-08-31 04:56:49 | Re: log_filename_prefix --> log_filename + strftime() |