Re: DSM segment handle generation in background workers - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: DSM segment handle generation in background workers
Date
Msg-id CAEepm=1+1jZiNHuRKaHgKZz1f=RFd8BnFpSgVsxEFNafjsqWZg@mail.gmail.com
Whole thread Raw
In response to Re: DSM segment handle generation in background workers  (Noah Misch <noah@leadboat.com>)
Responses Re: DSM segment handle generation in background workers
List 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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: PostgreSQL vs SQL/XML Standards
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: shared-memory based stats collector