From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
cc: Heikki Linnakangas <hlinnaka@iki.fi>, Peter Geoghegan <pg@bowt.ie>,
        Michael Paquier <michael@paquier.xyz>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        Adrien Nayrat <adrien.nayrat@anayrat.info>,
        Dmitry Dolgov <9erthalion6@gmail.com>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Vik Fearing <vik.fearing@2ndquadrant.com>,
        Robert Haas <robertmhaas@gmail.com>,
        David Rowley <david.rowley@2ndquadrant.com>,
        Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: random() (was Re: New GUC to sample log queries)
In-reply-to: 
 <CAEepm=2iTDYFafz8+P-CN84C3+hLm9aubedpFCez+m+SERKwMA@mail.gmail.com>
References: <20181129214850.kiq6mvofsgplqjdr@alvherre.pgsql>
 <3859.1545849900@sss.pgh.pa.us> <20181227013458.GF2106@paquier.xyz>
 <32696.1545875185@sss.pgh.pa.us>
 <CAH2-Wz=xJiy+BgU7M49L6EHSkMbJWbzbprge=AqyOC8aDXRj8A@mail.gmail.com>
 <2820.1545878340@sss.pgh.pa.us>
 <CAH2-WznuXsWmjnvbt=odKMVxpj1zutgzRb7s6Vu3VPXCjejS5g@mail.gmail.com>
 <CAEepm=1tJB2=w_GdXHRLkWQcCnFWGdmNiEdd5rupShKT=DwWyQ@mail.gmail.com>
 <9703.1545939393@sss.pgh.pa.us> <10913.1546038905@sss.pgh.pa.us>
 <26722.1546043812@sss.pgh.pa.us>
 <CAEepm=2iTDYFafz8+P-CN84C3+hLm9aubedpFCez+m+SERKwMA@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@enterprisedb.com>
	message dated "Sat, 29 Dec 2018 13:45:59 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27583.1546045067.1@sss.pgh.pa.us>
Date: Fri, 28 Dec 2018 19:57:47 -0500
Message-ID: <27584.1546045067@sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@enterprisedb.com> writes:
> I was going to suggest that we might be able to use a single
> not-visible-to-users number that is mixed into the existing recipe, so
> that we only ever read urandom once for the cluster.

Yeah, I was thinking along similar lines, but there's a problem:
InitProcessGlobals runs before an EXEC_BACKEND child has reconnected
to shared memory, so there's no cheap way to pass state to it.
No doubt there are ways around that, but I'd just as soon avoid
adding complexity here.  If we broke it somehow, the likely results
would be silent failure of the per-process seed to be random, which
might escape detection for a long time.

> But it sounds
> like it's not a problem, and it's probably better to just pass the
> whole problem over to the OS.

Yeah, that's what I'm thinking.

			regards, tom lane