Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Peter Geoghegan <pg@bowt.ie>, Michael Paquier <michael@paquier.xyz>, Alvaro Herrera <alvherre@2ndquadrant.com>, Adrien Nayrat <adrien.nayrat@anayrat.info>, 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-29T00:57:47Z
Lists: pgsql-hackers 
Thomas Munro <thomas.munro@enterprisedb.com> writes:
> I was going to suggest that we might be able to use a single
> not-visible-to-users number that is mixed into the existing recipe, so
> that we only ever read urandom once for the cluster.

Yeah, I was thinking along similar lines, but there's a problem:
InitProcessGlobals runs before an EXEC_BACKEND child has reconnected
to shared memory, so there's no cheap way to pass state to it.
No doubt there are ways around that, but I'd just as soon avoid
adding complexity here.  If we broke it somehow, the likely results
would be silent failure of the per-process seed to be random, which
might escape detection for a long time.

> But it sounds
> like it's not a problem, and it's probably better to just pass the
> whole problem over to the OS.

Yeah, that's what I'm thinking.

			regards, tom lane

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