Re: [PATCH] Log PostgreSQL version number on startup

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Christoph Berg <christoph(dot)berg(at)credativ(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Log PostgreSQL version number on startup
Date: 2019-01-16 19:58:48
Message-ID: 92bfdfdf-4164-aec5-4e32-c26e67821c38@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
0001-postmaster-Start-syslogger-earlier.patch text/plain 5.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-01-16 20:50:20 Re: insensitive collations
Previous Message Alvaro Herrera 2019-01-16 19:32:20 Re: speeding up planning with partitions