From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
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 00:10:17 -0400
Message-ID: <1664.1558325417@sss.pgh.pa.us> (raw)
In-Reply-To: <20190520012728.GC1923@paquier.xyz>
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>
<20190520012728.GC1923@paquier.xyz>
Michael Paquier <michael@paquier.xyz> writes:
> 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,
[ pokes at that... ] Hah, it proves the syslogger restart logic
works anyway. Because when we restart the crashed syslogger,
we're doing so after shmem exists, so the asserts don't fire.
However, I had a sudden realization about this, which is that
we need to think harder about the question of how the startup
sequence interlocks with the possibility of a pre-existing
postmaster or orphan backends. There's code down inside
CreateDataDirLockFile that attempts to detect a pre-existing
postmaster, but if the postmaster died leaving orphan backends,
that interlock will not detect them. Where we will notice
surviving backends is where we look for a pre-existing shared
memory segment, which is down inside reset_shared.
And: we really should not do anything much to the data directory
until we know that no such old processes remain. Otherwise we
risk problems such as deleting active temp files.
This line of thought suggests that trying to fix things so that
we can launch child processes before creating shared memory
is the wrong thing, because it seriously risks creating problems
in the leftover-child-processes scenario.
This means that the change that 57431a911 wanted to make is only
going to be safe if we're willing to re-order things so that the
startup sequence is
* create datadir lock file
* create shmem
* launch syslogger
* create sockets
Historically we've opened the sockets before making shmem. I'm
not sure offhand if there's any compelling reason for that order
... but if there is, getting 57431a911 to work is a whole lot
trickier than we've been thinking.
regards, tom lane
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: tgl@sss.pgh.pa.us, michael@paquier.xyz, 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: <1664.1558325417@sss.pgh.pa.us>
* 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