Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
От | Tom Lane |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran |
Дата | |
Msg-id | 4575.1476728063@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with
a stronger way of generating ran
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: