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

  1. Increase the number of possible random seeds per time period.

  2. Refactor pid, random seed and start time initialization.

  3. Increase the number of different values used when seeding random().