At Fri, 20 Apr 2018 21:51:49 +0300, Alexander Kuzmenkov
<a.kuzmen...@postgrespro.ru> wrote in
<c7cd74db-dde3-49e7-cdde-b909b0fda...@postgrespro.ru>
> On 04/16/2018 05:54 AM, Kyotaro HORIGUCHI wrote:
> > We can provide a new command "pg_ctl logrotate" to hide the
> > details. (It cannot be executed by root, though.)
>
> I like this approach.
Thanks. I found that the SIGUSR1 path is already ignoring
rotation_disabled so we don't need bother with the flag.
> I looked at the patch and changed some things:
> - cleaned up the error messages
Thanks for cleaning up crude copy'n pastes and wording.
> - moved checkLogrotateSignal to postmaster.c, since it has no reason to
> - be in xlog.c
Agreed. But
there seem to be no convention that static function starts with a
lower case letter. checkControlFile initMasks are minor instances
but..
> - added some documentation I had from my older patch
>
> Other than that, it looks good to me. The updated patch is attached.
Thanks for the documentation, but I see a description for the
same objective and different measure just above there.
https://www.postgresql.org/docs/devel/static/logfile-maintenance.html
> Alternatively, you might prefer to use an external log rotation
> program if you have one that you are already using with other
...
> rotation, the logrotate program can be configured to work with
> log files from syslog.
It seems that the additional description needs to be meld into
this at the first place? And some caveat may be needed on failure
cases. And in the attached the comment for "if
(rotateion_requested)" is edited.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c0bf632cd4..068aec7b47 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -930,10 +930,30 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
<para>
Alternatively, you might prefer to use an external log rotation
program if you have one that you are already using with other
- server software. For example, the <application>rotatelogs</application>
- tool included in the <productname>Apache</productname> distribution
- can be used with <productname>PostgreSQL</productname>. To do this,
- just pipe the server's
+
+ server software. For example, <application>logrotate</application> can
+ also be used to collect log files produced by the built-in logging
+ collector. In this configuration, the location and names of the log files
+ are determined by logging collector,
+ and <application>logrotate</application> periodically archives these files.
+ There must be some way for <application>logrotate</application> to inform
+ the application that the log file it is using is going to be archived, and
+ that it must direct further output to a new file. This is commonly done
+ with a <literal>postrotate</literal> script that sends
+ a <literal>SIGHUP</literal> signal to the application, which then reopens
+ the log file. In <productname>PostgreSQL</productname>, this is achieved
+ using a
+ <literal>logrotate</literal> command
+ of <application>pg_ctl</application>. When the server receives this
+ command, it switches to the new log files according to its configuration
+ (see <xref linkend="runtime-config-logging-where"/>). If it is configured
+ to use a static file name, it will just reopen the file.
+ </para>
+ <para>
+ For another example, <application>logrotate</application> tool included in
+ the <productname>Apache</productname> distribution can also be used
+ with <productname>PostgreSQL</productname>. To do this, just pipe the
+ server's
<systemitem>stderr</systemitem> output to the desired program.
If you start the server with
<command>pg_ctl</command>, then <systemitem>stderr</systemitem>
@@ -958,23 +978,6 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
configured to work with log files from
<application>syslog</application>.
</para>
-
- <para>
- An external log rotation tool, such as <application>logrotate</application>, can also
- be used to collect log files produced by the built-in logging collector. In this
- configuration, the location and names of the log files are determined by logging
- collector, and <application>logrotate</application> periodically archives these files.
- There must be some way for <application>logrotate</application> to inform the application
- that the log file it is using is going to be archived, and that it must direct further
- output to a new file. This is commonly done with a <literal>postrotate</literal> script
- that sends a <literal>SIGHUP</literal> signal to the application, which then reopens the
- log file. In <productname>PostgreSQL</productname>, this is achieved using a
- <literal>logrotate</literal> command of <application>pg_ctl</application>. When the
- server receives this command, it switches to the new log files according to its
- configuration (see <xref linkend="runtime-config-logging-where"/>). If it is configured
- to use a static file name, it will just reopen the file.
- </para>
-
<para>
On many systems, however, <application>syslog</application> is not very reliable,
particularly with large log messages; it might truncate or drop messages
diff --git a/src/backend/postmaster/syslogger.c b/src/backend/postmaster/syslogger.c
index 58b759f305..41f036faad 100644
--- a/src/backend/postmaster/syslogger.c
+++ b/src/backend/postmaster/syslogger.c
@@ -388,7 +388,7 @@ SysLoggerMain(int argc, char *argv[])
{
/*
* Force rotation when both values are zero. It means the request
- * was sent by pg_rotate_logfile.
+ * was sent by pg_rotate_logfile or pg_ctl logrotate.
*/
if (!time_based_rotation && size_rotation_for == 0)
size_rotation_for = LOG_DESTINATION_STDERR | LOG_DESTINATION_CSVLOG;
