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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-04-19 14:57:49 | Re: postmaster hangs |
Previous Message | Rolf Staege | 2005-04-19 14:38:44 | postmaster hangs |