Matheus,
Thanks for the response. I disabled the errorlog monitor and after the postgres was bounced, errorlog is growing again!! I will revise the monitor script to run the pg_rotate_logfile function.
BTW, I did not purposely hid that piece of information. I just found out about it as I dug more into the problem.
Thanks.
Maria A Rossi
Database Administration
PGDS (US)
email: maria.rossi@us.pgds.com
cell phone: 517.256.4392
work phone: 517.367.3099
work phone extension: 23099
From: Matheus de Oliveira [mailto:matioli.matheus@gmail.com]
Sent: Friday, March 13, 2015 7:55 AM
To: Rossi, Maria
Cc: Shreeyansh Dba; Scott Ribe; Postgres Maillist
Subject: Re: [ADMIN] Errorlog empty
On Fri, Mar 13, 2015 at 7:02 AM, Rossi, Maria <maria.rossi@us.pgds.com> wrote:
Also, we have a monitor that checks the errorlog. This monitor appends the current log to an archive file (example, errorlog.201503), then touch a new ‘error.log’. After the touch, the new errorlog is not written to anymore, until postgres is bounced. I should also note that new error.log is owned by the monitor ID:
That is a very important bit of information that you seem to have hidden from the list since the beginning. If an external process is moving the file that PostgreSQL is currently writting to, then it must somehow make the PostgreSQL's logger process aware of that. To do that you can call pg_rotate_logfile function:
$ psql -c "SELECT pg_rotate_logfile()"
Although if you remove the file before calling it, you can lose some information in between, so I recommend using a log_filename that has date/time information (like the default one), so you can call pg_rotate_logfile, wait for PostgreSQL to create a new one, then you are safe to move the old ones to whatever location you want.
--
