Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on
Date: 2013-02-19 12:42:34
Message-ID: 5123733A.1090904@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 19.02.2013 14:31, Rafael Martinez wrote:
> In the way pg_rotate_logfile() and log_truncate_on_rotation = on work
> today, we have to stop postgres to truncate the log file if an
> unexpected situation happens and this is not always possible in a
> production system.
>
> If we need to run pg_rotate_logfile() manually in the middle of the
> month and we don't want to lose the data in the file that is going to
> be truncated, we will have to take a manual copy of it before running
> pg_rotate_logfile().

You can rm the log file, then do pg_rotate_logfile(). No need to stop
the system.

- Heikki

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Kroon 2013-02-19 12:50:26 Re: Nested xmlagg doesn't give a result 9.2.3
Previous Message Rafael Martinez 2013-02-19 12:31:51 Re: BUG #7890: wrong behaviour using pg_rotate_logfile() with parameter log_truncate_on_rotation = on