On Sat, Dec 29, 2018 at 1:37 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > 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".
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. But it sounds like it's not a problem, and it's probably better to just pass the whole problem over to the OS. -- Thomas Munro http://www.enterprisedb.com