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

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: pgsql-patches(at)postgresql(dot)org
Subject: Re: log_filename_prefix --> log_filename + strftime()
Date: 2004-08-27 19:08:36
Message-ID: 200408271308.36954.pgsql@bluepolka.net (view raw or flat)
Thread:
Lists: pgsql-patches
On Friday August 27 2004 1:03, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> > On Friday August 27 2004 12:41, Tom Lane wrote:
> >> BTW, as long as we are taking Apache as the de facto standard --- does
> >> the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense,
> >> or would something different be closer to the common practice with
> >> Apache?
> >
> > I should say, Apache rotatelogs takes a configurable filename and then
> > appends ".N" where N is the logfile start time epoch.  In one case, its
> > access_log.N, in another its error_log.N.
>
> Hmm ... there isn't any way to emulate that with strftime escapes,
> unless I missed the right one.

If you supply an escape, Apache will override that default epoch.  So I 
could see setting the default to "server_log" or "postgresql_log" or 
whatever, and making the default (with no escapes supplied) be the epoch.  
That would be easy tweak, and be much closer to Apache style.

Ed

Apache 1.3.31:

            if (use_strftime) {
                struct tm *tm_now;
                tm_now = gmtime(&tLogStart);
                strftime(buf2, sizeof(buf2), szLogRoot, tm_now);
            }
            else {
                sprintf(buf2, "%s.%010d", szLogRoot, (int) tLogStart);
            }


In response to

Responses

pgsql-patches by date

Next:From: Andreas PflugDate: 2004-08-27 19:08:51
Subject: Re: log_filename_prefix --> log_filename + strftime()
Previous:From: Tom LaneDate: 2004-08-27 19:03:47
Subject: Re: log_filename_prefix --> log_filename + strftime()

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