random() generates collisions too early

Hi guys,

after playing a bit with "select random();", it turned out that numbers
get repeated quite early in a sequence. Originally I set lower PID range
(echo "2048" >/proc/sys/kernel/pid_max), but it doesn't seem to affect
the results.

So, what I observed... First, I generated a set including 1000 randomly
generated numbers without setting a seed.

   touch numbers
   for i in {1..1000} ; do
     echo "select random();"|psql|head -n 3|tail -n 1 >>numbers
   done

Then, I continued in generating random numbers and tried to find the new
one in the set:

   for i in {1..10000} ; do
     if grep `echo "select random();"|psql|head -n 3|tail -n 1` numbers
; then
       echo "SUCCESS: $i" ; break
     fi
   done

To my surprise I'm able to find a collision very quickly, in first 1000
numbers usually.

Originally, I used psql calls to get random() value from different
processes on purpose, but it seems Noah got similar results when
random() is called in one process:

On 10/18/2013 02:10 AM, Noah Misch wrote:
 > sudo sysctl -w kernel.pid_max=2048
 > psql -c 'create unlogged table samp(c float8)'
 > for n in `seq 1 200000`; do psql -qc 'insert into samp values
(random())'; done
 >
 > The results covered only 181383 distinct values, and 68 values
repeated four
 > or five times each.  We should at least consider using a
higher-entropy seed.

As I was told this is not taken as a security issue, since random() is
not considered as a CSPRNG in any case, but as Noah said, we should
probably try to make it a bit better.

Also, I'd suggest to state explicitly in the doc, that random()
shouldn't be taken as CSPRNG, since I can imagine people blindly
believing that random() can be good enough for such use cases, just
because they see how many possible values they get from double-precision
type:
http://www.postgresql.org/docs/9.3/static/functions-math.html

Regards,
Honza