I just noticed that, since I retired pademelon in August, we have exactly no buildfarm coverage of --disable-strong-random code paths. What's more, because the vast majority of the buildfarm enables --with-openssl, we're mostly just testing the punt-to-OpenSSL variant of pg_strong_random. Checking the buildfarm database, the last builds that did anything different from that are
protosciurus | 2018-08-15 13:37:08 | checking which random number source to use... /dev/urandom pademelon | 2018-08-16 18:47:07 | checking which random number source to use... weak builtin PRNG castoroides | 2018-09-26 12:03:07 | checking which random number source to use... /dev/urandom locust | 2018-12-14 01:14:35 | checking which random number source to use... /dev/urandom frogfish | 2018-12-22 18:39:35 | checking which random number source to use... /dev/urandom anole | 2018-12-27 10:30:33 | checking which random number source to use... /dev/urandom gharial | 2018-12-27 13:30:46 | checking which random number source to use... /dev/urandom jacana | 2018-12-27 13:45:14 | checking which random number source to use... Windows native Do we need more coverage of the "Windows native" alternative? More urgently, what about the lack of --disable-strong-random coverage? I feel like we should either have a buildfarm critter or two testing that code, or decide that it's no longer interesting and rip it out. backend_random.c, to name just one place, has a complex enough !HAVE_STRONG_RANDOM code path that I don't feel comfortable letting it go totally untested. There's certainly a reasonable argument to be made that everybody should have /dev/urandom these days, or else be willing to install OpenSSL and let it figure out what to do. (Even my hoary old HPUX 10.20 box does have OpenSSL and a working entropy daemon to feed it; I was just intentionally not using that in the pademelon configuration.) regards, tom lane