Horton

Re: DSM segment handle generation in background workers

Noah Misch <noah@leadboat.com>

View thread View on postgr.es
From: Noah Misch <noah@leadboat.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-11-12T08:33:58Z
Lists: pgsql-hackers 
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?

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().