Re: Reopen logfile on SIGHUP

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Greg Stark <stark(at)mit(dot)edu>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reopen logfile on SIGHUP
Date: 2018-02-27 23:12:45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-02-27 22:32:41 +0000, Greg Stark wrote:
>> On 27 February 2018 at 14:41, Anastasia Lubennikova
>> <a(dot)lubennikova(at)postgrespro(dot)ru> wrote:
>>> Small patch in the attachment implements logfile reopeninig on SIGHUP.

>> HUP will cause Postgres to reload its config files. That seems like a
>> fine time to reopen the log files as well but it would be nice if
>> there was also some way to get it to *just* do that and not reload the
>> config files.

> Is that an actually important thing to be able to do?

Yeah, after further consideration I'm having a hard time seeing the point
of this patch. The syslogger already has plenty sufficient knobs for
controlling when it rotates its output file. If you're not using those,
I think the answer is to start using them, not to make the syslogger's
behavior even more complicated so you can avoid learning about them.

IOW, I think a fair response to this is "if you're using logrotate with
Postgres, you're doing it wrong". That was of some use back before we
spent so much sweat on the syslogger, but it's not a reasonable setup

There'd be a point to this perhaps in configurations *not* using the
syslogger, but it's patching the wrong place for that case. (I'm
not sure there is a right place, unfortunately --- we don't have any
good way to redirect postmaster stderr after launch, since so many
processes would have to individually redirect.)

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-02-27 23:14:50 Re: Sigh, I broke crake again
Previous Message Tom Kazimiers 2018-02-27 22:54:44 Re: Unexpected behavior with transition tables in update statement trigger