|From:||ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)|
|To:||Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>|
|Subject:||Re: Reopen logfile on SIGHUP|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> writes:
> Large percentage of postgres installations, for example PGDG packages
> for Debian/Ubuntu, assume by default that log management will be
> handled by extrernals tools such as logrotate.
> Unfortunately such tools have no way to tell postgres to reopen log
> file after rotation and forced to use copy-truncate strategy that
> leads to a loss of log messages which is unacceptable.
> Small patch in the attachment implements logfile reopeninig on SIGHUP.
> It only affects the file accessed by logging collector, which name you
> can check with pg_current_logfile().
> I hope you will find this feature useful.
+1 for the feature, but:
> syslogFile = logfile_open(last_file_name, "a", false);
This will cause a fatal error if opening the logfile fails for any
reason (even transient errors like ENFILE/EMFILE). There is already the
logfile_rotate() function that can reopen log files safely based on time
and date limits. I'd suggest extending that by adding a config option
that controls whether to always reopen the log file on SIGHUP.
- Twitter seems more influential [than blogs] in the 'gets reported in
the mainstream press' sense at least. - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
to a mainstream media article. - Calle Dybedahl
|Next Message||Catalin Iacob||2018-02-27 16:38:21||Re: prokind column (was Re: [HACKERS] SQL procedures)|
|Previous Message||Robert Haas||2018-02-27 16:05:14||Re: [HACKERS] path toward faster partition pruning|