Re: DSM segment handle generation in background workers
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Noah Misch <noah@leadboat.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-11-12T10:11:19Z
Lists: pgsql-hackers
On Mon, Nov 12, 2018 at 9:34 PM Noah Misch <noah@leadboat.com> wrote: > On Sat, Oct 13, 2018 at 11:45:17PM +1300, Thomas Munro wrote: > > + /* Set a different seed for random() in every backend. */ > > + srandom((unsigned int) MyProcPid ^ (unsigned int) MyStartTimestamp); > > > - TimestampDifference(0, port->SessionStartTime, &secs, &usecs); > > - srandom((unsigned int) (MyProcPid ^ (usecs << 12) ^ secs)); > > Compared to the old code, the new code requires more wall time to visit every > possible seed value. New code xor's the PID bits into the fastest-changing > timestamp bits, so only about twenty bits can vary within any given one-second > period. (That assumes a PID space of twenty or fewer bits; fifteen bits is > the Linux default.) Is that aspect of the change justified? Hmm, right. How about applying pg_bswap32() to one of the terms, as an easy approximation of reversing the bits? -- Thomas Munro http://www.enterprisedb.com
Commits
-
Increase the number of possible random seeds per time period.
- 5b0ce3ec334b 12.0 landed
-
Refactor pid, random seed and start time initialization.
- 197e4af9d5da 12.0 landed
-
Increase the number of different values used when seeding random().
- 98c50656cac2 9.4.0 cited