pgsql: Make syslogger more robust against failures in opening CSV logf - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Make syslogger more robust against failures in opening CSV logf
Date
Msg-id E1ftzgY-0000RT-Ns@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Make syslogger more robust against failures in opening CSV log files.

The previous coding figured it'd be good enough to postpone opening
the first CSV log file until we got a message we needed to write there.
This is unsafe, though, because if the open fails we end up in infinite
recursion trying to report the failure.  Instead make the CSV log file
management code look as nearly as possible like the longstanding logic
for the stderr log file.  In particular, open it immediately at postmaster
startup (if enabled), or when we get a SIGHUP in which we find that
log_destination has been changed to enable CSV logging.

It seems OK to fail if a postmaster-start-time open attempt fails, as
we've long done for the stderr log file.  But we can't die if we fail
to open a CSV log file during SIGHUP, so we're still left with a problem.
In that case, write any output meant for the CSV log file to the stderr
log file.  (This will also cover race-condition cases in which backends
send CSV log data before or after we have the CSV log file open.)

This patch also fixes an ancient oversight that, if CSV logging was
turned off during a SIGHUP, we never actually closed the last CSV
log file.

In passing, remember to reset whereToSendOutput = DestNone during syslogger
start, since (unlike all other postmaster children) it's forked before the
postmaster has done that.  This made for a platform-dependent difference
in error reporting behavior between the syslogger and other children:
except on Windows, it'd report problems to the original postmaster stderr
as well as the normal error log file(s).  It's barely possible that that
was intentional at some point; but it doesn't seem likely to be desirable
in production, and the platform dependency definitely isn't desirable.

Per report from Alexander Kukushkin.  It's been like this for a long time,
so back-patch to all supported branches.

Discussion: https://postgr.es/m/CAFh8B==iLUD_gqC-dAENS0V+kVrCeGiKujtKqSQ7++S-caaChw@mail.gmail.com

Branch
------
REL_11_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/f8fc5f5f50dbabec866dee79cd739bb3f68052a1

Modified Files
--------------
src/backend/postmaster/syslogger.c | 162 ++++++++++++++++++++++++++++---------
1 file changed, 123 insertions(+), 39 deletions(-)


pgsql-committers by date:

Previous
From: Jeff Davis
Date:
Subject: pgsql: Reconsider new file extension in commit 91f26d5f.
Next
From: Thomas Munro
Date:
Subject: pgsql: Fix typos.