Heikki Linnakangas <heikki.linnakangas@iki.fi> writes:
> Replace PostmasterRandom() with a stronger way of generating randomness.
This patch broke padmeleon:
016-10-17 09:57:17.782 EDT [5804d8bd.57c2:1] LOG: database system was shut down at 2016-10-17 09:57:17 EDT
2016-10-17 09:57:17.790 EDT [5804d8bd.57c2:2] LOG: MultiXact member wraparound protections are now enabled
2016-10-17 09:57:17.807 EDT [5804d8bd.57c6:1] LOG: autovacuum launcher started
2016-10-17 09:57:17.820 EDT [5804d8bd.57bf:1] LOG: database system is ready to accept connections
2016-10-17 09:57:18.516 EDT [5804d8bd.57bf:2] LOG: could not generate random query cancel key
2016-10-17 09:57:19.544 EDT [5804d8bd.57bf:3] LOG: could not generate random query cancel key
2016-10-17 09:57:20.563 EDT [5804d8bd.57bf:4] LOG: could not generate random query cancel key
2016-10-17 09:57:21.584 EDT [5804d8bd.57bf:5] LOG: could not generate random query cancel key
2016-10-17 09:57:22.604 EDT [5804d8bd.57bf:6] LOG: could not generate random query cancel key
It's failing because this machine lacks /dev/random and /dev/urandom.
It does have a non-kernel entropy daemon (prngd), which OpenSSL knows how
to read from but the hard-wired code in pg_strong_random() does not.
I'm not sure whether it's worth trying to make pg_strong_random() aware
of prngd. The real issue here is whether we are willing to say that
Postgres simply does not work anymore on machines without standard entropy
sources. Doesn't matter whether the user cares about the strength of
cancel keys, we're just blowing them off. That seems a bit extreme
from here. I think we should be willing to fall back to the old code
if we can't find a real entropy source.
regards, tom lane