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

Re: Postgres Log rotation not working in 8.0.2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pallav Kalva <pkalva(at)deg(dot)cc>
Cc: pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Postgres Log rotation not working in 8.0.2
Date: 2005-04-19 14:46:46
Message-ID: 21521.1113922006@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-admin
Pallav Kalva <pkalva(at)deg(dot)cc> writes:
> I am sorry for the confusion, what i meant was the oldest entry on the 
> log file was on last monday and most recent was this morning and the 
> file didnt rotate yet.

Looking at the code, it will have decided to append not truncate because
%U hadn't changed from the preceding value:

     * Decide whether to overwrite or append.  We can overwrite if (a)
     * Log_truncate_on_rotation is set, (b) the rotation was triggered by
     * elapsed time and not something else, and (c) the computed file name
     * is different from what we were previously logging into.

There's also a funny involved in the first rotation after startup,
although in your situation case (c) would've prevented overwrite anyway:

     * Note: during the first rotation after forking off from the postmaster,
     * last_file_name will be NULL.  (We don't bother to set it in the
     * postmaster because it ain't gonna work in the EXEC_BACKEND case.)
     * So we will always append in that situation, even though truncating
     * would usually be safe.

So my advice remains "wait till this Thursday before complaining".

			regards, tom lane

In response to

pgsql-admin by date

Next:From: Tom LaneDate: 2005-04-19 14:57:49
Subject: Re: postmaster hangs
Previous:From: Rolf StaegeDate: 2005-04-19 14:38:44
Subject: postmaster hangs

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