From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com> |
Subject: | Re: Support getrandom() for pg_strong_random() source |
Date: | 2025-10-10 00:11:26 |
Message-ID: | CAOYmi+kYYEuX3R_fVyVOnCU1-Rt_j2wzE6sF2O6VvQPdKHcT-Q@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 9, 2025 at 4:53 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> Does it mean that we introduce something like pg_fast_random() and
> packagers can select it as the random number generation function
> instead of pg_strong_random()? Or can packagers select the function
> used in pg_strong_random()?
The latter -- packagers should be able to select the implementation of
pg_strong_random(). I think pg_fast_random() is likely to be a bad
abstraction if we don't have more use cases to guide it.
> All of these sound reasonable to me. I think we can handle this as two
> separate discussions: one for the UUID implementation changes, and
> another for the pg_strong_random() modifications (which would cover
> both the runtime switching for superusers and the compile-time
> alternatives for packagers).
Sounds good to me. (Which would you like this thread to be?)
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-10-10 00:52:36 | Re: Replace O_EXCL with O_TRUNC for creation of state.tmp in SaveSlotToPath |
Previous Message | Masahiko Sawada | 2025-10-09 23:52:29 | Re: Support getrandom() for pg_strong_random() source |