Re: Poor buildfarm coverage of strong-random alternatives

I wrote:
> Further to this ... I was just doing some measurements to see how much
> it'd add to backend startup time if we start using pg_strong_random()
> to set the initial random seed. The answer, at least on my slightly
> long-in-the-tooth RHEL6 box, is "about 25 usec using /dev/urandom,
> or about 80 usec using OpenSSL". So I'm wondering why configure is
> coded to prefer OpenSSL.
> I'm going to go do some timing checks on some other platforms, but
> this result suggests that we may need to question that choice.

Further testing (on Fedora, macOS, FreeBSD, and NetBSD) has confirmed
that the OpenSSL code path is 2x to 3x slower than the /dev/urandom
code path for fetching half a dozen random bytes. So I'm still
wondering why the current preference order. My mental model of
this is that on platforms with /dev/*random, OpenSSL's RAND_bytes
isn't doing much more than wrapping /dev/*random --- so is it
really doing anything we need?

regards, tom lane