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.
Regards,
--
Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres