On Sun, May 19, 2019 at 02:19:40PM -0400, Tom Lane wrote:
> Done. I went ahead and pushed it, but if the buildfarm shows any
> sign of unhappiness I'll just revert it.
I have not tested on Windows this one, but on Linux with EXEC_BACKEND
the test is still not able to detect correctly the failures of the
syslogger if one reverts 8334515 to re-enable the early syslogger
startup, so that's a bit disappointing, and on the contrary
culicidae's run frequency and its detection of the problem are good :(
The trick is that the postmaster does not complain on that as we are
still in early stages of initialization. Still it can be found in
the logs redirected to stderr.
I got some ideas on how to improve the detection unfortunately I think
that these are rather fragile as the syslogger keeps restarting:
- Switch all the assertions in *_shmem.c to elog(FATAL) or just
elog(PANIC) to ease their detection in the logs.
- Track for any FATAL or PANIC, or even assertions failures in the log
files generated at early stages when starting the server.
- Have a GUC switch to never restart the syslogger in case of a
failure, still at realy stages we'll run into issues because the GUC
configuration may not be loaded?
Tracking the syslogger via pg_stat_activity is not an option either as
we don't want to connect it to shared memory by design. We cannot
either increase read_backend_variables(), as all its errors go to
stderr.
Ideas are welcome.
--
Michael
