Re: Support getrandom() for pg_strong_random() source

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support getrandom() for pg_strong_random() source
Date: 2025-07-22 07:13:24
Message-ID: aH86FEl-AWFPv87s@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

> 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..
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-07-22 07:18:22 Re: Log prefix missing for subscriber log messages received from publisher
Previous Message Michael Paquier 2025-07-22 07:05:34 Re: Missing NULL check after calling ecpg_strdup