From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        Adrien Nayrat <adrien.nayrat@anayrat.info>,
        Thomas Munro <thomas.munro@enterprisedb.com>,
        Dmitry Dolgov <9erthalion6@gmail.com>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Vik Fearing <vik.fearing@2ndquadrant.com>,
        Robert Haas <robertmhaas@gmail.com>,
        Michael Paquier <michael@paquier.xyz>,
        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: 
 <CAH2-WznZ6_nsLyC8cDb2BicRSQ-Ldyd=d2Kivpx2YSp_5mtwPw@mail.gmail.com>
References: <20181129214850.kiq6mvofsgplqjdr@alvherre.pgsql>
 <3859.1545849900@sss.pgh.pa.us>
 <CAH2-Wzk1Wa4TcrdOQv=eknY_NWyr2bTKf3rFtWPu06-V6LhE6A@mail.gmail.com>
 <5659.1545852666@sss.pgh.pa.us>
 <CAH2-Wz=MGrJ5G-FtKVDnWzVuj6P2imQ3QTydex2fDgQGHXfdew@mail.gmail.com>
 <CAH2-WznB-bx=AYpkWiRps1yy6QQaV8N=JWQSQvJM+fG4UZi4Og@mail.gmail.com>
 <14047.1545855555@sss.pgh.pa.us>
 <CAH2-WznZ6_nsLyC8cDb2BicRSQ-Ldyd=d2Kivpx2YSp_5mtwPw@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Wed, 26 Dec 2018 12:27:50 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21085.1545859306.1@sss.pgh.pa.us>
Date: Wed, 26 Dec 2018 16:21:46 -0500
Message-ID: <21086.1545859306@sss.pgh.pa.us>
Precedence: bulk

Peter Geoghegan <pg@bowt.ie> writes:
> On Wed, Dec 26, 2018 at 12:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Replacing random() might actually make that easier not harder, since
>> we'd have more control over what happens when.

> That does seem useful. I'm in favor. But why does the function to seed
> the internal PRNG have to be loadable? Can't it just be
> superuser-only?

That'd work as far as I'm concerned.  (But I can hear Frost wanting
a built-in role for it ;-))

One thing we'd have to think about if we want to take this seriously
is whether a process-wide PRNG state is really adequate; if you're
trying to make a particular call site be deterministic, you'd likely
wish it weren't interfered with by other call sites.  On the flip
side, having more call sites probably makes things more random and
thus better for normal usage.  Not sure how to resolve that tension
(but I don't want to build a whole lot of new infrastructure here).

			regards, tom lane