On Monday August 30 2004 11:07, Ed L. wrote:
> On Monday August 30 2004 10:56, Tom Lane wrote:
> > "Ed L." <pgsql@bluepolka.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 ...
This patch rotates logs on local time boundaries instead of UTC boundaries,
e.g., midnight local for daily rotation instead of midnight UTC. It does
so by parsing the "%z" result from strftime().
Correct me if I'm mistaken, but I *think* the correct behavior across DST
transitions may be an orthogonal issue. 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. I am arguing for
inclusion of this patch because 1) the utility of local time boundary
rotations exceeds the risk for us, and because 2) the risk can be mitigated
by a comment in the documentation and maybe postgresql.conf, and because 3)
I think the issue already exists and this doesn't make it worse.
Ed
