From: Christoph Berg <christoph.berg@credativ.de>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Log PostgreSQL version number on startup
Date: Tue, 29 Jan 2019 16:46:06 +0100
Message-ID: <20190129154605.GJ9860@msg.credativ.de> (raw)
In-Reply-To: <92bfdfdf-4164-aec5-4e32-c26e67821c38@2ndquadrant.com>
References: <20181121144611.GJ15795@msg.credativ.de>
<d5d50936-20b9-85f1-06bc-94a01c5040c1@2ndquadrant.com>
<92bfdfdf-4164-aec5-4e32-c26e67821c38@2ndquadrant.com>
Re: Peter Eisentraut 2019-01-16 <92bfdfdf-4164-aec5-4e32-c26e67821c38@2ndquadrant.com>
> > Why don't we start the logging collector before opening the sockets?
>
> Specifically, something like the attached.
>
> This keeps the dynamic module loading before the logging collector
> start, so we see those error messages on stderr, but then the setting up
> of the sockets would get logged.
This works nicely, so +1.
I'm attaching your patch as 0001 and my rebased one on top of it as
0002.
Christoph
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutzAttachments:
[text/x-diff] 0001-postmaster-Start-syslogger-earlier.patch (5.6K, ../20190129154605.GJ9860@msg.credativ.de/2-0001-postmaster-Start-syslogger-earlier.patch)
download | inline diff:
From d876be48c3f5beca5da6cb19e804ab0307409f80 Mon Sep 17 00:00:00 2001
From: Christoph Berg <christoph.berg@credativ.de>
Date: Tue, 29 Jan 2019 16:26:04 +0100
Subject: [PATCH 1/2] postmaster: Start syslogger earlier
---
src/backend/postmaster/postmaster.c | 120 ++++++++++++++--------------
1 file changed, 60 insertions(+), 60 deletions(-)
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.cindex 3052bbbc21..119c01d745 100644--- a/src/backend/postmaster/postmaster.c+++ b/src/backend/postmaster/postmaster.c@@ -992,6 +992,66 @@ PostmasterMain(int argc, char *argv[])
*/
InitializeMaxBackends();
+ /*+ * Initialize pipe (or process handle on Windows) that allows children to+ * wake up from sleep on postmaster death.+ */+ InitPostmasterDeathWatchHandle();++ /*+ * Forcibly remove the files signaling a standby promotion request.+ * Otherwise, the existence of those files triggers a promotion too early,+ * whether a user wants that or not.+ *+ * This removal of files is usually unnecessary because they can exist+ * only during a few moments during a standby promotion. However there is+ * a race condition: if pg_ctl promote is executed and creates the files+ * during a promotion, the files can stay around even after the server is+ * brought up to new master. Then, if new standby starts by using the+ * backup taken from that master, the files can exist at the server+ * startup and should be removed in order to avoid an unexpected+ * promotion.+ *+ * Note that promotion signal files need to be removed before the startup+ * process is invoked. Because, after that, they can be used by+ * postmaster's SIGUSR1 signal handler.+ */+ RemovePromoteSignalFiles();++ /* Do the same for logrotate signal file */+ RemoveLogrotateSignalFiles();++ /* Remove any outdated file holding the current log filenames. */+ if (unlink(LOG_METAINFO_DATAFILE) < 0 && errno != ENOENT)+ ereport(LOG,+ (errcode_for_file_access(),+ errmsg("could not remove file \"%s\": %m",+ LOG_METAINFO_DATAFILE)));++ /*+ * If enabled, start up syslogger collection subprocess+ */+ SysLoggerPID = SysLogger_Start();++ /*+ * Reset whereToSendOutput from DestDebug (its starting state) to+ * DestNone. This stops ereport from sending log messages to stderr unless+ * Log_destination permits. We don't do this until the postmaster is+ * fully launched, since startup failures may as well be reported to+ * stderr.+ *+ * If we are in fact disabling logging to stderr, first emit a log message+ * saying so, to provide a breadcrumb trail for users who may not remember+ * that their logging is configured to go somewhere else.+ */+ if (!(Log_destination & LOG_DESTINATION_STDERR))+ ereport(LOG,+ (errmsg("ending log output to stderr"),+ errhint("Future log output will go to log destination \"%s\".",+ Log_destination_string)));++ whereToSendOutput = DestNone;+
/*
* Establish input sockets.
*
@@ -1183,12 +1243,6 @@ PostmasterMain(int argc, char *argv[])
*/
set_stack_base();
- /*- * Initialize pipe (or process handle on Windows) that allows children to- * wake up from sleep on postmaster death.- */- InitPostmasterDeathWatchHandle();-
#ifdef WIN32
/*
@@ -1242,60 +1296,6 @@ PostmasterMain(int argc, char *argv[])
*/
RemovePgTempFiles();
- /*- * Forcibly remove the files signaling a standby promotion request.- * Otherwise, the existence of those files triggers a promotion too early,- * whether a user wants that or not.- *- * This removal of files is usually unnecessary because they can exist- * only during a few moments during a standby promotion. However there is- * a race condition: if pg_ctl promote is executed and creates the files- * during a promotion, the files can stay around even after the server is- * brought up to new master. Then, if new standby starts by using the- * backup taken from that master, the files can exist at the server- * startup and should be removed in order to avoid an unexpected- * promotion.- *- * Note that promotion signal files need to be removed before the startup- * process is invoked. Because, after that, they can be used by- * postmaster's SIGUSR1 signal handler.- */- RemovePromoteSignalFiles();-- /* Do the same for logrotate signal file */- RemoveLogrotateSignalFiles();-- /* Remove any outdated file holding the current log filenames. */- if (unlink(LOG_METAINFO_DATAFILE) < 0 && errno != ENOENT)- ereport(LOG,- (errcode_for_file_access(),- errmsg("could not remove file \"%s\": %m",- LOG_METAINFO_DATAFILE)));-- /*- * If enabled, start up syslogger collection subprocess- */- SysLoggerPID = SysLogger_Start();-- /*- * Reset whereToSendOutput from DestDebug (its starting state) to- * DestNone. This stops ereport from sending log messages to stderr unless- * Log_destination permits. We don't do this until the postmaster is- * fully launched, since startup failures may as well be reported to- * stderr.- *- * If we are in fact disabling logging to stderr, first emit a log message- * saying so, to provide a breadcrumb trail for users who may not remember- * that their logging is configured to go somewhere else.- */- if (!(Log_destination & LOG_DESTINATION_STDERR))- ereport(LOG,- (errmsg("ending log output to stderr"),- errhint("Future log output will go to log destination \"%s\".",- Log_destination_string)));-- whereToSendOutput = DestNone;-
/*
* Initialize stats collection subsystem (this does NOT start the
* collector process!)
--
2.20.1
[text/x-diff] 0002-Log-PostgreSQL-version-number-on-startup.patch (986B, ../20190129154605.GJ9860@msg.credativ.de/3-0002-Log-PostgreSQL-version-number-on-startup.patch)
download | inline diff:
From 8e8fa64cdefdbebfecb431b766def198ac9ad673 Mon Sep 17 00:00:00 2001
From: Christoph Berg <christoph.berg@credativ.de>
Date: Wed, 21 Nov 2018 15:43:34 +0100
Subject: [PATCH 2/2] Log PostgreSQL version number on startup
Logging the PostgreSQL version on startup is useful for two reasons:
There is a clear marker in the log file that a new postmaster is
beginning, and it's useful for tracking the server version across
startup while upgrading.
---
src/backend/postmaster/postmaster.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.cindex 119c01d745..40a0222220 100644--- a/src/backend/postmaster/postmaster.c+++ b/src/backend/postmaster/postmaster.c@@ -1052,6 +1052,10 @@ PostmasterMain(int argc, char *argv[])
whereToSendOutput = DestNone;
+ /* Report server startup in log */+ ereport(LOG,+ (errmsg("starting %s", PG_VERSION_STR)));+
/*
* Establish input sockets.
*
--
2.20.1
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: christoph.berg@credativ.de, peter.eisentraut@2ndquadrant.com
Subject: Re: [PATCH] Log PostgreSQL version number on startup
In-Reply-To: <20190129154605.GJ9860@msg.credativ.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox