On 04/11/2018 12:00 AM, Tom Lane wrote:
> Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru> writes:
>> Syslogger does already rotate logs properly on SIGHUP under some
>> conditions, so we can just change this to unconditional rotation.
>> Probably some people wouldn't want their logs to be rotated on SIGHUP,
>> so we could also add a GUC to control this. Please see the attached patch.
> I don't believe this meets the "not break other use-cases" requirement.
>
> Point 1: I do not like a solution that presumes that some background
> daemon is going to SIGHUP the postmaster whenever it feels like it.
> That will break scenarios in which the DBA is in the midst of a set
> of related configuration changes (either ALTER SYSTEM commands or
> manual postgresql.conf edits) and doesn't want those changes applied
> till she's done. So we need a mechanism that's narrowly targeted
> to reopening the logfile, without SIGHUP'ing the entire database.
If logging collector can reopen file on SIGUSR1, then maybe there should
be logging_collector.pid file in PGDATA, so external rotation tools can
get it without much trouble?
>
> Point 2: Depending on how you've got the log filenames configured,
> setting rotation_requested may result in a change in log filename, which
> will be the wrong thing in some use-cases, particularly that of an
> external logrotate daemon that only wishes you'd close and reopen your
> file descriptor. This is a pre-existing issue with the SIGUSR1 code path,
> which I think hasn't come up only because hardly anybody is using that.
> If we're going to make it mainstream, we need to think harder about how
> that ought to work.
External tools usually rely on logfile name staying the same. PGDG
distribution do it that way for sure.
>
> Anastasia's original patch avoided the point-2 pitfall, but didn't
> do anything about point 1.
>
> BTW, another thing that needs to be considered is the interaction with
> rotation_disabled. Right now we automatically drop that on SIGHUP, but
> I'm unclear on whether it should be different for logrotate requests.
>
> regards, tom lane
>
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company