Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
Date: 2016-10-17 18:14:23
Message-ID: 4575.1476728063@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Heikki Linnakangas <hlinnaka(at)iki(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2016-10-17 20:03:04 Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
Previous Message Heikki Linnakangas 2016-10-17 17:48:58 Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2016-10-17 18:15:38 Re: [PATCH] Better logging of COPY queries if log_statement='all'
Previous Message Kenaniah Cerny 2016-10-17 18:05:49 Idempotency for all DDL statements