From: Noah Misch <noah@leadboat.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Something fishy happening on frogmouth
Date: Sat, 15 Sep 2018 15:15:46 -0700
Message-ID: <20180915221546.GA3159382@rfd.leadboat.com> (raw)
In-Reply-To: <CA+Tgmoa477p+T6n5Sh_qRSvzj8TPYoJgve0tmAGt5cpLta8FSA@mail.gmail.com>
References: <6557.1383073940@sss.pgh.pa.us>
<CA+Tgmob859sdnDuHAF31BE55qEoREnCzzWeqDbgkNB0d_F+zmA@mail.gmail.com>
<20131030124734.GA11429@awork2.anarazel.de>
<CA+Tgmoa477p+T6n5Sh_qRSvzj8TPYoJgve0tmAGt5cpLta8FSA@mail.gmail.com>
On Wed, Oct 30, 2013 at 09:07:43AM -0400, Robert Haas wrote:
> On Wed, Oct 30, 2013 at 8:47 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2013-10-30 08:45:03 -0400, Robert Haas wrote:
> >> If I'm reading this correctly, the last three runs on frogmouth have
> >> all failed, and all of them have failed with a complaint about,
> >> specifically, Global/PostgreSQL.851401618. Now, that really shouldn't
> >> be happening, because the code to choose that number looks like this:
> >>
> >> dsm_control_handle = random();
> > Could it be that we haven't primed the random number generator with the
> > time or something like that yet?
>
> Yeah, I think that's probably what it is.
I experienced a variation of this, namely a RHEL 7 system where initdb always
says "selecting dynamic shared memory implementation ... sysv". Each initdb
is rejecting posix shm by probing the same ten segments:
$ strace initdb -D scratch 2>&1 | grep /dev/shm/P
open("/dev/shm/PostgreSQL.1804289383", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EEXIST (File exists)
open("/dev/shm/PostgreSQL.846930886", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EEXIST (File exists)
open("/dev/shm/PostgreSQL.1681692777", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EEXIST (File exists)
open("/dev/shm/PostgreSQL.1714636915", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EEXIST (File exists)
open("/dev/shm/PostgreSQL.1957747793", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EEXIST (File exists)
open("/dev/shm/PostgreSQL.424238335", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EEXIST (File exists)
open("/dev/shm/PostgreSQL.719885386", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EEXIST (File exists)
open("/dev/shm/PostgreSQL.1649760492", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EEXIST (File exists)
open("/dev/shm/PostgreSQL.596516649", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EEXIST (File exists)
open("/dev/shm/PostgreSQL.1189641421", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = -1 EEXIST (File exists)
Regular postmaster runs choose a random segment, but initdb, bootstrap
postgres, and single-user postgres all start with the same segment. These
segments are months old. Perhaps I was testing something that caused a
bootstrap postgres to crash. After ten such crashes, future initdb runs
considered posix shm unusable.
> There's PostmasterRandom()
> to initialize the random-number generator on first use, but that
> doesn't help if some other module calls random(). I wonder if we
> ought to just get rid of PostmasterRandom() and instead have the
> postmaster run that initialization code very early in startup.
Usually, the first srandom() call happens early in PostmasterMain(). I plan
to add one to InitStandaloneProcess(), which substitutes for several tasks
otherwise done in PostmasterMain(). That seems like a good thing even if DSM
weren't in the picture. Also, initdb needs an srandom() somewhere;
choose_dsm_implementation() itself seems fine. Attached. With this, "make
-j20 check-world" selected posix shm and passed even when I forced DSM
creation to fail on unseeded random():
inline patch 1: src/backend/storage/ipc/dsm_impl.c (+3/-0 lines) download inline-1.patch--- a/src/backend/storage/ipc/dsm_impl.c+++ b/src/backend/storage/ipc/dsm_impl.c@@ -249,2 +249,5 @@ dsm_impl_posix(dsm_op op, dsm_handle handle, Size request_size,+ if (handle == 1804289383)+ elog(ERROR, "generated handle with no randomness");+
snprintf(name, 64, "/PostgreSQL.%u", handle);
Patches and attachments:download all (2 files, .tar.gz)dsm-standalone-random-v1.patch (text/plain, 837B) downloaddiff --git a/src/backend/utils/init/miscinit.c b/src/backend/utils/init/miscinit.cindex 865119d..f003831 100644--- a/src/backend/utils/init/miscinit.c+++ b/src/backend/utils/init/miscinit.c@@ -325,6 +325,8 @@ InitStandaloneProcess(const char *argv0)
MyStartTime = time(NULL); /* set our start time in case we call elog */
+ srandom((unsigned int) (MyProcPid ^ MyStartTime));+
/* Initialize process-local latch support */
InitializeLatchSupport();
MyLatch = &LocalLatchData;
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.cindex 32746c7..83f4b0b 100644--- a/src/bin/initdb/initdb.c+++ b/src/bin/initdb/initdb.c@@ -922,6 +922,8 @@ choose_dsm_implementation(void)
#ifdef HAVE_SHM_OPEN
int ntries = 10;
+ srandom((unsigned int) (getpid() ^ time(NULL)));+
while (ntries > 0)
{
uint32 handle;
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-hackers@postgresql.org
Cc: noah@leadboat.com, robertmhaas@gmail.com, andres@2ndquadrant.com, tgl@sss.pgh.pa.us, andrew@dunslane.net
Subject: Re: Something fishy happening on frogmouth
In-Reply-To: <20180915221546.GA3159382@rfd.leadboat.com>
* 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