pgsql: Make syslogger more robust against failures in opening CSV logf

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Make syslogger more robust against failures in opening CSV logf
Дата
Msg-id E1ftzgY-0000RT-Ns@gemulon.postgresql.org
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: pgsql: Reconsider new file extension in commit 91f26d5f.
Следующее
От: Thomas Munro
Дата:
Сообщение: pgsql: Fix typos.