From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Yuli Khodorkovskiy <yuli.khodorkovskiy@crunchydata.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND
Date: Mon, 20 May 2019 10:27:28 +0900
Message-ID: <20190520012728.GC1923@paquier.xyz> (raw)
In-Reply-To: <2702.1558289980@sss.pgh.pa.us>
References: <20190516060628.GE1415@paquier.xyz>
<20190517042536.GM20887@paquier.xyz>
<20190517202443.gw4zdfkpwgsjdel6@alap3.anarazel.de>
<20190518093522.GA19212@paquier.xyz>
<28565.1558196308@sss.pgh.pa.us>
<20190519004344.GA3653@paquier.xyz>
<22995.1558278322@sss.pgh.pa.us>
<27719.1558282181@sss.pgh.pa.us>
<16df9d01-8b03-2664-a18c-16c40186f5ab@2ndQuadrant.com>
<2702.1558289980@sss.pgh.pa.us>
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
Attachments:
[application/pgp-signature] signature.asc (832B, ../20190520012728.GC1923@paquier.xyz/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: michael@paquier.xyz, tgl@sss.pgh.pa.us, andrew.dunstan@2ndquadrant.com, andres@anarazel.de, peter.eisentraut@2ndquadrant.com, yuli.khodorkovskiy@crunchydata.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15804: Assertion failure when using logging_collector with EXEC_BACKEND
In-Reply-To: <20190520012728.GC1923@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox