Re: DSM segment handle generation in background workers

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Noah Misch <noah(at)leadboat(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 10:11:19
Message-ID: CAEepm=1+1jZiNHuRKaHgKZz1f=RFd8BnFpSgVsxEFNafjsqWZg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 12, 2018 at 9:34 PM Noah Misch <noah(at)leadboat(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2018-11-12 11:10:42 Re: shared-memory based stats collector
Previous Message Pavel Stehule 2018-11-12 09:58:17 Re: PostgreSQL vs SQL/XML Standards