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 <pe...@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
