Re: Reopen logfile on SIGHUP

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reopen logfile on SIGHUP
Дата
Msg-id 16946.1523394033@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Reopen logfile on SIGHUP  (Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>)
Ответы Re: Reopen logfile on SIGHUP  (Grigory Smolkin <g.smolkin@postgrespro.ru>)
Re: Reopen logfile on SIGHUP  (Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>)
Список pgsql-hackers
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.

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.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: lazy detoasting