On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier <mich...@paquier.xyz> wrote: > My understanding of the problem is that it is a choice of efficiency > vs entropy, and that it's not really possible to have both parts of > the cake.
That was my understanding too, but then [1] called that into question. If -- and I don't really have enough expertise to verify that "if" -- the reason OpenSSL is slower isn't because of "entropy", but because of operations and safety checks that it has to ask the kernel to make for it, then it stands to reason that the kernel could do that a lot faster. If it turns out that's not the case (the post at [1] is ten years old; things change, or Adam could have been wrong, or...), I think that getentropy() is still a straight upgrade from /dev/urandom, due to its increased safety guarantees at startup. > If we make that configurable, documentation sounds like the > key point to me, to explain which one has more benefits over the > other. Agreed. > Could getentropy() be more efficient at the end on most platforms, > meaning that this could limit the meaning of having a GUC switch? I don't know. [2] implies that the performance comparison depends on several factors, and falls in favor of OpenSSL when the number of bytes per call is large -- but our use of pg_strong_random() is generally on small buffers. We would need to do a _lot_ more research before, say, switching any defaults. Thanks, --Jacob [1] https://www.imperialviolet.org/2015/10/17/boringssl.html [2] https://dotat.at/@/2024-10-01-getentropy.html
