On Wed, Oct 30, 2013 at 8:47 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers