Re: Support getrandom() for pg_strong_random() source - Mailing list pgsql-hackers

From Dagfinn Ilmari Mannsåker
Subject Re: Support getrandom() for pg_strong_random() source
Date
Msg-id 87ikjkiio1.fsf@wibble.ilmari.org
Whole thread Raw
In response to Support getrandom() for pg_strong_random() source  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Support getrandom() for pg_strong_random() source
List pgsql-hackers
Masahiko Sawada <sawada.mshk@gmail.com> writes:

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

getrandom() is Linux-specific, while getentropy() is specified by POSIX
(since 2024).  It was originally introduced by OpenBSD 5.6 in 2014, and
was added to macOS 10.12 in 2016, glibc 2.25 (same as getrandom()) in
2017, musl 1.1.20 and FreeBSD 12.0 in 2018, and NetBSD 10.0 in 2024

Sources: 

https://pubs.opengroup.org/onlinepubs/9799919799/functions/getentropy.html
https://dotat.at/@/2024-10-01-getentropy.html

So I think it's more worthwhile to add support for getentropy() than
getrandom().

- ilmari



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Issues with hash and GiST LP_DEAD setting for kill_prior_tuple
Next
From: Andrei Lepikhov
Date:
Subject: Re: MergeAppend could consider sorting cheapest child path