> On 21 Jul 2020, at 17:31, David Steele <da...@pgmasters.net> wrote: > On 7/21/20 8:13 AM, Daniel Gustafsson wrote:
>> Another thing that stood out when reviewing this code is that we optimize for >> RAND_poll failing in pg_strong_random, when we already have RAND_status >> checking for a sufficiently seeded RNG for us. ISTM that we can simplify the >> code by letting RAND_status do the work as per 0002, and also (while >> unlikely) >> survive any transient failures in RAND_poll by allowing all the retries we've >> defined for the loop. > > I wonder how effective the retries are going to be if they happen > immediately. However, most of the code paths I followed ended in a hard error > when pg_strong_random() failed so it may not hurt to try. I just worry that > some caller is depending on a faster failure here. There is that, but I'm not convinced that relying on specific timing for anything RNG or similarly cryptographic-related is especially sane. cheers ./daniel
