pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feed[PATCH 2/2] Log PostgreSQL version number on startup
12+ messages / 4 participants
[nested] [flat]
* [PATCH 2/2] Log PostgreSQL version number on startup
@ 2018-11-21 14:43 Christoph Berg <christoph.berg@credativ.de>
0 siblings, 0 replies; 12+ messages in thread
From: Christoph Berg @ 2018-11-21 14:43 UTC (permalink / raw)
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.c
index 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
--24zk1gE8NUlDmwG9--
^ permalink raw reply [nested|flat] 12+ messages in thread
* [PATCH] Log PostgreSQL version number on startup
@ 2018-11-21 14:46 Christoph Berg <christoph.berg@credativ.de>
0 siblings, 3 replies; 12+ messages in thread
From: Christoph Berg @ 2018-11-21 14:46 UTC (permalink / raw)
To: pgsql-hackers
Hi,
it has bugged me for a long time that there's no clear "PostgreSQL is
starting" message in the server log file. I'd like to change that for
two reasons:
* when reading a long log file, it's not entirely clear where a new
server startup begins.
It was worse in the past (first message was "database system was
shut down at..." which rather looks like a shutdown message to
newbie users), now it's "listening on IPv6..." but that message
might possibly become DEBUG1, or listen_addresses might become
changeable at run-time
* while upgrading servers, it's useful to know which server version
was actually started if there are several startup attempts
The change would be to log "Starting PG_VERSION_STR" as early as
possible.
A startup looks like this:
2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv6 address "::1", port 5431
2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv4 address "127.0.0.1", port 5431
2018-11-21 15:19:47.315 CET [24453] LOG: listening on Unix socket "/tmp/.s.PGSQL.5431"
2018-11-21 15:19:47.394 CET [24453] LOG: starting PostgreSQL 12devel on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.2.0-9) 8.2.0, 64-bit
2018-11-21 15:19:47.426 CET [24454] LOG: database system was shut down at 2018-11-21 15:15:35 CET
2018-11-21 15:19:47.460 CET [24453] LOG: database system is ready to accept connections
(I'd rather put the start message before the listening messages, but I
think the startup message should be logged via logging_collector, and
listening is logged before the log file is opened.)
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/datenschutz
Attachments:
[text/x-diff] 0001-Log-PostgreSQL-version-number-on-startup.patch (1.0K, ../../20181121144611.GJ15795@msg.credativ.de/2-0001-Log-PostgreSQL-version-number-on-startup.patch)
download | inline diff:
From 49f786a26110ca55d12c47f75e8662047e78c5c8 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] 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.c
index a33a131182..e0abfd686a 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -1306,6 +1306,10 @@ PostmasterMain(int argc, char *argv[])
whereToSendOutput = DestNone;
+ /* Report server startup in log */
+ ereport(LOG,
+ (errmsg("starting %s", PG_VERSION_STR)));
+
/*
* Initialize stats collection subsystem (this does NOT start the
* collector process!)
--
2.19.1
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCH] Log PostgreSQL version number on startup
@ 2018-11-21 16:32 Stephen Frost <sfrost@snowman.net>
parent: Christoph Berg <christoph.berg@credativ.de>
2 siblings, 1 reply; 12+ messages in thread
From: Stephen Frost @ 2018-11-21 16:32 UTC (permalink / raw)
To: Christoph Berg <christoph.berg@credativ.de>; pgsql-hackers
Greetings,
* Christoph Berg (christoph.berg@credativ.de) wrote:
> it has bugged me for a long time that there's no clear "PostgreSQL is
> starting" message in the server log file. I'd like to change that for
> two reasons:
+1
> * when reading a long log file, it's not entirely clear where a new
> server startup begins.
>
> It was worse in the past (first message was "database system was
> shut down at..." which rather looks like a shutdown message to
> newbie users), now it's "listening on IPv6..." but that message
> might possibly become DEBUG1, or listen_addresses might become
> changeable at run-time
>
> * while upgrading servers, it's useful to know which server version
> was actually started if there are several startup attempts
>
> The change would be to log "Starting PG_VERSION_STR" as early as
> possible.
>
> A startup looks like this:
>
> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv6 address "::1", port 5431
> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv4 address "127.0.0.1", port 5431
> 2018-11-21 15:19:47.315 CET [24453] LOG: listening on Unix socket "/tmp/.s.PGSQL.5431"
> 2018-11-21 15:19:47.394 CET [24453] LOG: starting PostgreSQL 12devel on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.2.0-9) 8.2.0, 64-bit
> 2018-11-21 15:19:47.426 CET [24454] LOG: database system was shut down at 2018-11-21 15:15:35 CET
> 2018-11-21 15:19:47.460 CET [24453] LOG: database system is ready to accept connections
>
> (I'd rather put the start message before the listening messages, but I
> think the startup message should be logged via logging_collector, and
> listening is logged before the log file is opened.)
I wonder if maybe we should do both (though with an appropriate "logs
now being logged through the logging collector" or some such).
I've not really looked at the patch at all, but definitely like the
idea.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (818B, ../../20181121163246.GR3415@tamriel.snowman.net/2-signature.asc)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCH] Log PostgreSQL version number on startup
@ 2018-12-10 06:33 Michael Paquier <michael@paquier.xyz>
parent: Stephen Frost <sfrost@snowman.net>
0 siblings, 1 reply; 12+ messages in thread
From: Michael Paquier @ 2018-12-10 06:33 UTC (permalink / raw)
To: Stephen Frost <sfrost@snowman.net>; +Cc: Christoph Berg <christoph.berg@credativ.de>; pgsql-hackers
On Wed, Nov 21, 2018 at 11:32:46AM -0500, Stephen Frost wrote:
> * Christoph Berg (christoph.berg@credativ.de) wrote:
>> it has bugged me for a long time that there's no clear "PostgreSQL is
>> starting" message in the server log file. I'd like to change that for
>> two reasons:
>
> +1
+1. One complain which could be formulated is that this makes the
logs at startup more noisy. Now your patch has an issue if you want to
ensure that this information gets added to the log files, because at
this stage of startup the GUCs are not loaded, hence this is sent to
stderr, and perhaps not on the log files.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20181210063307.GD1105@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCH] Log PostgreSQL version number on startup
@ 2018-12-10 09:57 Christoph Berg <christoph.berg@credativ.de>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 12+ messages in thread
From: Christoph Berg @ 2018-12-10 09:57 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Stephen Frost <sfrost@snowman.net>; pgsql-hackers
Re: Michael Paquier 2018-12-10 <20181210063307.GD1105@paquier.xyz>
> On Wed, Nov 21, 2018 at 11:32:46AM -0500, Stephen Frost wrote:
> > * Christoph Berg (christoph.berg@credativ.de) wrote:
> >> it has bugged me for a long time that there's no clear "PostgreSQL is
> >> starting" message in the server log file. I'd like to change that for
> >> two reasons:
> >
> > +1
>
> +1. One complain which could be formulated is that this makes the
> logs at startup more noisy. Now your patch has an issue if you want to
> ensure that this information gets added to the log files, because at
> this stage of startup the GUCs are not loaded, hence this is sent to
> stderr, and perhaps not on the log files.
I placed it so that it gets logged after logging_collector is active.
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/datenschutz
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCH] Log PostgreSQL version number on startup
@ 2019-01-02 21:10 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Christoph Berg <christoph.berg@credativ.de>
2 siblings, 1 reply; 12+ messages in thread
From: Peter Eisentraut @ 2019-01-02 21:10 UTC (permalink / raw)
To: Christoph Berg <christoph.berg@credativ.de>; pgsql-hackers
On 21/11/2018 15:46, Christoph Berg wrote:
> 2018-11-21 15:19:47.394 CET [24453] LOG: starting PostgreSQL 12devel on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.2.0-9) 8.2.0, 64-bit
Do we want to do the whole version string, or just "PostgreSQL 12devel"?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCH] Log PostgreSQL version number on startup
@ 2019-01-04 23:54 Stephen Frost <sfrost@snowman.net>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 12+ messages in thread
From: Stephen Frost @ 2019-01-04 23:54 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Christoph Berg <christoph.berg@credativ.de>; pgsql-hackers
Greetings,
* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 21/11/2018 15:46, Christoph Berg wrote:
> > 2018-11-21 15:19:47.394 CET [24453] LOG: starting PostgreSQL 12devel on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.2.0-9) 8.2.0, 64-bit
>
> Do we want to do the whole version string, or just "PostgreSQL 12devel"?
The whole thing.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (818B, ../../20190104235451.GL2528@tamriel.snowman.net/2-signature.asc)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCH] Log PostgreSQL version number on startup
@ 2019-01-05 01:12 Michael Paquier <michael@paquier.xyz>
parent: Stephen Frost <sfrost@snowman.net>
0 siblings, 0 replies; 12+ messages in thread
From: Michael Paquier @ 2019-01-05 01:12 UTC (permalink / raw)
To: Stephen Frost <sfrost@snowman.net>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Christoph Berg <christoph.berg@credativ.de>; pgsql-hackers
On Fri, Jan 04, 2019 at 06:54:51PM -0500, Stephen Frost wrote:
> * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
>> Do we want to do the whole version string, or just "PostgreSQL 12devel"?
>
> The whole thing.
I would prefer the whole string as well, as that's useful to look
after all the details not only related to a given minor version, like
a build tagged with an internal compilation system number added with
configure's extra-version.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20190105011230.GB4849@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCH] Log PostgreSQL version number on startup
@ 2019-01-05 14:53 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Christoph Berg <christoph.berg@credativ.de>
2 siblings, 1 reply; 12+ messages in thread
From: Peter Eisentraut @ 2019-01-05 14:53 UTC (permalink / raw)
To: Christoph Berg <christoph.berg@credativ.de>; pgsql-hackers
On 21/11/2018 15:46, Christoph Berg wrote:
> A startup looks like this:
>
> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv6 address "::1", port 5431
> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv4 address "127.0.0.1", port 5431
> 2018-11-21 15:19:47.315 CET [24453] LOG: listening on Unix socket "/tmp/.s.PGSQL.5431"
> 2018-11-21 15:19:47.394 CET [24453] LOG: starting PostgreSQL 12devel on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.2.0-9) 8.2.0, 64-bit
> 2018-11-21 15:19:47.426 CET [24454] LOG: database system was shut down at 2018-11-21 15:15:35 CET
> 2018-11-21 15:19:47.460 CET [24453] LOG: database system is ready to accept connections
>
> (I'd rather put the start message before the listening messages, but I
> think the startup message should be logged via logging_collector, and
> listening is logged before the log file is opened.)
Why don't we start the logging collector before opening the sockets?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCH] Log PostgreSQL version number on startup
@ 2019-01-16 19:58 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 12+ messages in thread
From: Peter Eisentraut @ 2019-01-16 19:58 UTC (permalink / raw)
To: Christoph Berg <christoph.berg@credativ.de>; pgsql-hackers
On 05/01/2019 15:53, Peter Eisentraut wrote:
> On 21/11/2018 15:46, Christoph Berg wrote:
>> A startup looks like this:
>>
>> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv6 address "::1", port 5431
>> 2018-11-21 15:19:47.259 CET [24453] LOG: listening on IPv4 address "127.0.0.1", port 5431
>> 2018-11-21 15:19:47.315 CET [24453] LOG: listening on Unix socket "/tmp/.s.PGSQL.5431"
>> 2018-11-21 15:19:47.394 CET [24453] LOG: starting PostgreSQL 12devel on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.2.0-9) 8.2.0, 64-bit
>> 2018-11-21 15:19:47.426 CET [24454] LOG: database system was shut down at 2018-11-21 15:15:35 CET
>> 2018-11-21 15:19:47.460 CET [24453] LOG: database system is ready to accept connections
>>
>> (I'd rather put the start message before the listening messages, but I
>> think the startup message should be logged via logging_collector, and
>> listening is logged before the log file is opened.)
>
> 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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 0a482552d26488ec5ce8e4d7bad12bf25ba44c8b Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Wed, 16 Jan 2019 17:32:01 +0100
Subject: [PATCH] postmaster: Start syslogger earlier
XXX
---
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.c
index a707d4d465..36efd908bb 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
Attachments:
[text/plain] 0001-postmaster-Start-syslogger-earlier.patch (5.6K, ../../92bfdfdf-4164-aec5-4e32-c26e67821c38@2ndquadrant.com/2-0001-postmaster-Start-syslogger-earlier.patch)
download | inline diff:
From 0a482552d26488ec5ce8e4d7bad12bf25ba44c8b Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Wed, 16 Jan 2019 17:32:01 +0100
Subject: [PATCH] postmaster: Start syslogger earlier
XXX
---
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.c
index a707d4d465..36efd908bb 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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCH] Log PostgreSQL version number on startup
@ 2019-01-29 15:46 Christoph Berg <christoph.berg@credativ.de>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 12+ messages in thread
From: Christoph Berg @ 2019-01-29 15:46 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: pgsql-hackers
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/datenschutz
Attachments:
[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.c
index 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.c
index 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
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: [PATCH] Log PostgreSQL version number on startup
@ 2019-01-30 22:29 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Christoph Berg <christoph.berg@credativ.de>
0 siblings, 0 replies; 12+ messages in thread
From: Peter Eisentraut @ 2019-01-30 22:29 UTC (permalink / raw)
To: Christoph Berg <christoph.berg@credativ.de>; pgsql-hackers
On 29/01/2019 16:46, Christoph Berg wrote:
> 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.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2019-01-30 22:29 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-11-21 14:43 [PATCH 2/2] Log PostgreSQL version number on startup Christoph Berg <christoph.berg@credativ.de>
2018-11-21 14:46 [PATCH] Log PostgreSQL version number on startup Christoph Berg <christoph.berg@credativ.de>
2018-11-21 16:32 ` Stephen Frost <sfrost@snowman.net>
2018-12-10 06:33 ` Michael Paquier <michael@paquier.xyz>
2018-12-10 09:57 ` Christoph Berg <christoph.berg@credativ.de>
2019-01-02 21:10 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-01-04 23:54 ` Stephen Frost <sfrost@snowman.net>
2019-01-05 01:12 ` Michael Paquier <michael@paquier.xyz>
2019-01-05 14:53 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-01-16 19:58 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2019-01-29 15:46 ` Christoph Berg <christoph.berg@credativ.de>
2019-01-30 22:29 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
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