Re: Random not so random

On Mon, 4 Oct 2004, Tom Lane wrote:

> "Arnau Rebassa" <arebassa(at)hotmail(dot)com> writes:
>> I'm using a debian linux as OS with a 2.4 kernel running on it.
>
>>> Incidentally, are you reconnecting every time or is it that multiple calls
>>> in a single session are returning the same record?
>
>> I'm reconnecting each time I want to retrieve a message.
>
> Hmm. postmaster.c does this during startup of each backend process:
>
> gettimeofday(&now, &tz);
> srandom((unsigned int) now.tv_usec);
>
> which would ordinarily be fairly good at mixing things up. On some
> platforms I might worry that the microseconds part of gettimeofday
> might only have a few bits of accuracy, but I don't think that's an
> issue on Linux.
>
> It occurs to me that you might be seeing predictability as an indirect
> result of something else you are doing that somehow tends to synchronize
> the backend start times. Are you connecting from a cron script that
> would tend to be launched at the same relative instant within a second?
>
> It might improve matters to make the code do something like
>
> srandom((unsigned int) (now.tv_sec ^ now.tv_usec));

How about reading from /dev/urandom on platforms that support it?

Actually, that should be done each time the random() function
is evaluated. (I have no familiarity with the code, so please
bear with me if the suggestion is unsound). I'd even add a parameter
for "really" random data to be provided, by reading /dev/random
instead of /dev/urandom (but read(2) may block).

How about the following:
random() = random(0) = traditional random()
random(1) = best effort random() via /dev/urandom
random(2) = wait for really random bits via /dev/random

.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo(at)ESI(dot)it