Heikki Linnakangas <hlinnaka@iki.fi> writes:
> I'm going to try implementing prngd support. It seems easy enough, and
> prngd can be run on modern systems too, which is important for testing it.
OK, if you feel like doing the work. However:
> In addition to that, I'm going to see if we can make postmaster to work
> sensibly without query cancel keys, if pg_strong_random() fails.
This seems like a lot of work, with the "reward" that we'd start getting
hard-to-debug reports about query cancel not working. Anytime anyone
ever says "cancel didn't seem to work" we'd have to wonder whether there
had been a transient failure of pg_strong_random. I think if we're
going to refuse to generate weak cancel keys, we should just fail,
not silently fall into a functionally degraded state.
But in general, I think that being this picky about cancel keys on systems
that are too old to have /dev/random is not really helpful to anybody.
I don't recall any reports of anyone ever having a DOS situation from
weak cancel keys. It's fine to upgrade our practice where it's convenient
to do that, but taking away functionality on systems where it's not
convenient isn't improving anyone's life.
pg_crypto has a different set of tradeoffs and I don't necessarily make
the same argument there. I don't feel that cancel keys have to act the
same as pg_crypto keys.
regards, tom lane