From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DSM segment handle generation in background workers |
Date: | 2018-11-12 08:33:58 |
Message-ID: | 20181112083358.GA1073796@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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?
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2018-11-12 09:23:51 | Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT |
Previous Message | John Naylor | 2018-11-12 07:50:30 | doc fix for pg_stat_activity.backend_type |