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();
>>
>> One possibility that occurs to me is that if, for some reason, we're
>> using the same handle every time on Windows, and if Windows takes a
>> bit of time to reclaim the segment after the postmaster exits (which
>> is not hard to believe given some previous Windows behavior I've
>> seen), then running the postmaster lots of times in quick succession
>> (as initdb does) might fail. I dunno what that has to do with the
>> patch, though.
>
> 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. 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. That'd
make the timing of the random number generator being initialized a bit
more predictable, perhaps, but if the dynamic shared memory code is
going to grab a random number during startup it's basically going to
be nailed to that event anyway.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company