Re: Random strings - Mailing list pgsql-patches

From Joe Conway
Subject Re: Random strings
Date
Msg-id 02ac01c12048$40312020$48d210ac@jecw2k1
Whole thread Raw
In response to Re: Random strings  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Random strings
List pgsql-patches
> > Per the discussion yesterday, here's a patch. There are two versions of
> > essentially the same function. They both take an int as the number of
> > requested random bytes, and generate a random binary string of the
requested
> > length from /dev/urandom. The first one (randomstr_hex) converts the
binary
> > to hex and returns it as text, and the other (randomstr_bytea) does the
> > needed escaping of special characters and returns bytea.
>
> Perhaps one of these returning bytea would be enough and you can use
> the new encode functions to convert them to a format of choice.  Also, why
> aren't you using /dev/random?

Very nice. I hadn't looked encode/decode yet. I'll rework the patch and just
leave the bytea as you suggested.

As far as /dev/random, the issue it that it blocks when it runs out of
entropy. As a small test, I recompiled with /dev/random and tried:

   select randomstr_bytea(8), foo from bar;

where bar has about 120 rows. I was still waiting a minute later. When
requesting one at a time (but resubmitting relatively quickly), it works
fine until about the 35th request in a row, then it blocks briefly (~2
seconds). The same test with /dev/urandom returns instantly. Perhaps there
should be an option to use either. For instances where only a few truly
random bytes is needed (i.e. one session key), use /dev/random. When you
need many random bytes quickly, use /dev/urandom?

-- Joe



pgsql-patches by date:

Previous
From: Anders Bengtsson
Date:
Subject: JDBC Statement cleanup patch
Next
From: Bruce Momjian
Date:
Subject: Re: JDBC Statement cleanup patch