| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Support getrandom() for pg_strong_random() source |
| Date: | 2025-07-30 21:03:53 |
| Message-ID: | CAOYmi+nLraamk5LCc_JC=TYuDL5vwcXKmKuOhy6my9-o2oJr5w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 30, 2025 at 12:58 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> I imagine a "get entropy" operation could be very slow or even blocking,
> whereas a random number generator might just have to do some arithmetic
> starting from the previous seed state.
Agreed -- it could absolutely be slower, but if it's not slower in
practice in a user's environment, is there a problem with using it as
the basis for pg_strong_random()? That doesn't seem "wrong" to me; it
just seems like a tradeoff that would take investigation.
(The "blocking" fear is related to the research I linked above -- we
don't really want our CSPRNG to block in the way that /dev/random used
to, because that's not helpful. But we absolutely want it to block if
the CSPRNG state hasn't initialized yet. The goal continues to be
strength over performance IMO -- but there is circumstantial evidence
here that getentropy() could maybe get us both, in some environments.)
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-07-30 23:55:48 | Re: Support getrandom() for pg_strong_random() source |
| Previous Message | Sami Imseih | 2025-07-30 20:09:08 | Re: track generic and custom plans in pg_stat_statements |