On Tue, Jul 22, 2025 at 12:13 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> > The patch supports the getrandom() function as a new source of
> > pg_strong_random(). The getrandom() function uses the same source as
> > the /dev/urandom device but it seems much faster than opening,
> > reading, and closing /dev/urandom. Here is the execution time of
> > generating 1 million UUIDv4 data measured on my environment:
> >
> > HEAD(/dev/urandom): 1863.064 ms
> > Patched(getrandom()): 516.627 ms
>
> Interesting. Are there platforms where this is not available? I'd be
> pretty sure that some animals in the buildfarm would not like this
> suggestion but I'm saying it anyway. Perhaps we could even drop
> /dev/urandom?
As far as I know macOS doesn't support getrandom() but supports
getentropy() instead. And an older glibc version might not support it.
It's supported since Linux 3.17 and glibc 2.25.
> > I guess that while OpenSSL's RAND_bytes() should still be prioritized
> > where available it might be a good idea to support getrandom() for
> > builds where RAND_bytes() is not available.
> >
> > Feedback is very welcome.
>
> I am wondering how much non-OpenSSL builds matter these days, TBH, so
> I am not sure that this is worth the addition of an extra
> configure/meson check and this stuff has its cost just for such
> builds. I am not saying that we should make OpenSSL mandatory, of
> course not, but all production instances of Postgres have likely
> OpenSSL enabled anyway. Perhaps some embedded deployments like
> --without-openssl, who knows..
Fair point. In fact, I was not using OpenSSL and just realized
generating UUID by PostgreSQL's uuidv4() and uuidv7() was much slower
than generating it by Rust's UUID crate. On my environment,
getrandom() is faster than RAND_bytes() so I thought there are some
cases where users want to use the getrandom() source rather than
RAND_bytes(), but I'm not sure since there is also a difference in the
secureness.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
