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: <10913.1546038905@sss.pgh.pa.us>
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>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 28 Dec 2018 18:15:05 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26721.1546043812.1@sss.pgh.pa.us>
Date: Fri, 28 Dec 2018 19:36:52 -0500
Message-ID: <26722.1546043812@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Looking at this, I seem to remember that we considered doing exactly this
> awhile ago, but refrained because there was concern about depleting the
> system's reserve of entropy if we have a high backend spawn rate, and it
> didn't seem like there was a security reason to insist on unpredictable
> random() results.  However, the log-sampling patch destroys the latter
> argument.  As for the former argument, I'm not sure how big a deal that
> really is.  Presumably, the act of spawning a backend would itself
> contribute some more entropy to the pool (particularly if a network
> connection is involved), so the depletion problem might be fictitious
> in the first place.  Also, a few references I consulted, such as the
> Linux urandom(4) man page, suggest that even in a depleted-entropy
> state the results of reading /dev/urandom should be random enough
> for all but the very strictest security requirements.

I did some experimentation, watching /proc/sys/kernel/random/entropy_avail
while continuously spawning backends, and I can't see any difference in
behavior with or without this patch.  If there is any effect at all, it's
completely swamped by other noise (and there's a lot of noise, even on a
machine that's idle).

Also, further googling says there's a pretty sizable body of opinion that
Linux's available-entropy calculation is bogus anyway: once the system's
acquired a reasonable amount of entropy, no amount of reading from
/dev/urandom will cause the randomness of the results to decrease.
So there's no reason to be concerned about whether we're reading it
"too much".

			regards, tom lane