Re: Reopen logfile on SIGHUP

From: Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Reopen logfile on SIGHUP
Date: 2018-04-11 00:19:06
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 04/11/2018 12:00 AM, Tom Lane wrote:
> Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)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 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:
The Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-04-11 00:26:43 Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process
Previous Message Thomas Munro 2018-04-11 00:17:14 Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process