From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
cc: Noah Misch <noah@leadboat.com>
Subject: Unexpected "shared memory block is still in use"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <22223.1557340366.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 08 May 2019 14:32:46 -0400
Message-ID: <22224.1557340366@sss.pgh.pa.us>
Precedence: bulk

Just now, while running a parallel check-world on HEAD according to the
same script I've been using for quite some time, one of the TAP tests
died during initdb:

selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default timezone ... America/New_York
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... 2019-05-08 13:59:19.963 EDT [=
18351] FATAL:  pre-existing shared memory block (key 5440004, ID 173447580=
2) is still in use
2019-05-08 13:59:19.963 EDT [18351] HINT:  Terminate any old server proces=
ses associated with data directory "/home/postgres/pgsql/src/test/subscrip=
tion/tmp_check/t_004_sync_publisher_data/pgdata".
child process exited with exit code 1
initdb: removing data directory "/home/postgres/pgsql/src/test/subscriptio=
n/tmp_check/t_004_sync_publisher_data/pgdata"
Bail out!  system initdb failed

I have never seen this happen before in the TAP tests.

I think the odds are very high that this implies something wrong with
commit c09850992.

My immediate guess after eyeballing that patch quickly is that it was
not a good idea to redefine the rules used by bootstrap/standalone
backends.  In particular, it seems somewhat plausible that the bootstrap
process hadn't yet completely died when the standalone backend for the
post-bootstrap phase came along and decided there was a conflict (which
it never would have before).

			regards, tom lane