Tom Lane wrote, On 2015-01-19 16:22:
> 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.
It's a purportedly random sequence that turns out not to be random, with
not even a caveat in the manual. That's a bug.
> 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.
That's a good argument for not backporting such a change and documenting
the caveats instead in current versions. On the other hand, migrating a
database to a different platform, or sharing test data with people in
other platforms, can also bite that user by producing a different
sequence. I ran into this issue myself when I started to prepare a
reproducible test case for a problem in an external application using
randomized data with known values. Instead of sending a short file that
generates the data at random and tweaks the necessary values to trigger
the problem, I may be forced to send a ~1Gb file because of this issue.
> 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.
Me too, but my choice of setseed(1) should have been just as good as
any, according to the manual. Also it doesn't solve the bigger problem
of platform dependency I'm having. Relying on the system's generator is
known to be problematic. The least-effort approach is to tweak the
manual to add the corresponding caveats, but that's a poor solution.
> 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.
pgcrypto doesn't have seeding, so neither of these solutions solves this
problem except if we force the other party to install that extension
too, which isn't really a viable solution.
