On Tue, Jul 21, 2020 at 10:36:53PM +0200, Daniel Gustafsson wrote: > I think the original intention was to handle older OpenSSL versions where > multiple successful RAND_poll calls were required for RAND_status to succeed, > the check working as an optimization since a failing RAND_poll would render > all > efforts useless anyway. I'm not sure this is true for the OpenSSL versions we > support in HEAD, and/or for modern platforms, but without proof of it not > being > useful I would opt for keeping it.
Yeah, the retry loop refers to this part of the past discussion on the matter: https://www.postgresql.org/message-id/CAEZATCWYs6rAp36VKm4W7Sb3EF_7tNcRuhcnJC1P8=8w9nb...@mail.gmail.com During the rewrite of the RNG engines, there was also a retry logic introduced in 75e2c87, then removed in c16de9d for 1.1.1. In short, we may be able to live without that once we cut more support for OpenSSL versions (minimum version support of 1.1.1 is a couple of years ahead at least for us), but I see no reasons to not leave that in place either. And this visibly solved one problem for us. I don't see either a reason to not simplify the loop to fall back to RAND_status() for the validation. In short, the proposed patch set looks like a good idea to me to stick with the recommendations of upstream's wiki to use RAND_poll() after a fork, but only do that on HEAD (OpenSSL 1.1.0 mixes the current timestamp and the PID in the random seed of the default engine, 1.0.2 only the PID but RAND_cleanup is a no-op only after 1.1.0). -- Michael
signature.asc
Description: PGP signature
