Re: BUG #12589: Poor randomness from random() with some seeds; poor resolution - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #12589: Poor randomness from random() with some seeds; poor resolution
Date
Msg-id 25876.1421680975@sss.pgh.pa.us
Whole thread Raw
In response to BUG #12589: Poor randomness from random() with some seeds; poor resolution  (pgsql-004@personal.formauri.es)
Responses Re: BUG #12589: Poor randomness from random() with some seeds; poor resolution  (Pedro Gimeno <pgsql-004@personal.formauri.es>)
List pgsql-bugs
pgsql-004@personal.formauri.es writes:
> [ setseed(1) behaves poorly on glibc platforms ]
> PostgreSQL should probably use its own pseudo-random number generator and
> not depend on the system's,

This is not a bug; it's a feature request, and a rather poorly grounded
one at that.  If the user uses setseed(), he probably cares about getting
the same sequence every time, and would not thank us for rolling in a
different implementation with different behavior.

(You could try griping to the glibc folk for providing a poor random()
function on your platform, but I suspect they'd give largely the same
answer.)

Having said that, I think that most of your problem here stems from using
an extremal value for the argument of setseed().  I get saner-looking
behavior wih a seed of 0 or 0.1, or even 0.999999.

We could possibly redefine setseed to take a range of -1 < x < 1 rather
than -1 <= x <= 1, although that might break things unnecessarily for
users on other platforms where srandom() doesn't have this odd corner
case.

            regards, tom lane

PS: also, if you have need of something better than random(), you could
consider using pgcrypto's random number generator, or writing your own
as an extension.

pgsql-bugs by date:

Previous
From: Devrim Gündüz
Date:
Subject: Re: BUG #12598: pgpool 9.4 broken online recovery node
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #12571: Web site documentation error for make_timestamp