Horton

Re: random() (was Re: New GUC to sample log queries)

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Alvaro Herrera <alvherre@2ndquadrant.com>, Adrien Nayrat <adrien.nayrat@anayrat.info>, Thomas Munro <thomas.munro@enterprisedb.com>, Dmitry Dolgov <9erthalion6@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Vik Fearing <vik.fearing@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, David Rowley <david.rowley@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-12-27T02:20:20Z
Lists: pgsql-hackers 
On Wed, Dec 26, 2018 at 5:46 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think pg_strong_random is overkill, and overly expensive, for
> most if not all of the existing callers of random().  We already
> changed the ones where it's important to be strong ...

+1.

There was a controversy a bit like this in the Python community a few
years ago [1]. I don't think you can trust somebody to write Postgres
backend code but not trust them to understand the security issues with
a fast user-space PRNG (I think that I'd be willing to say the same
thing about people that write Python programs of any consequence).

It's always possible to make a change that might stop someone from
introducing a bug. The question ought to be: why this change, and why
now?

[1] https://lwn.net/Articles/657269/
-- 
Peter Geoghegan

Commits

  1. Use pg_strong_random() to select each server process's random seed.

  2. Use a separate random seed for SQL random()/setseed() functions.

  3. Marginal performance hacking in erand48.c.

  4. Fix latent problem with pg_jrand48().

  5. Silence compiler warning

  6. Add log_statement_sample_rate parameter