Re: random() (was Re: New GUC to sample log queries)
| От | Tom Lane |
|---|---|
| Тема | Re: random() (was Re: New GUC to sample log queries) |
| Дата | |
| Msg-id | 26722.1546043812@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: random() (was Re: New GUC to sample log queries) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: random() (was Re: New GUC to sample log queries)
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: