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: Peter Geoghegan <pg@bowt.ie>
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-28T21:42:20Z
Lists: pgsql-hackers

Attachments

I wrote:
> On further reflection, it seems likely that in most installations a lot
> of processes never invoke drandom()/setseed() at all, making such work
> in InitProcessGlobals a waste of cycles.  Probably a better idea is to
> have drandom() initialize the seed on first use, if it wasn't already
> set by setseed().

Here's a proposed patch for that.

It occurs to me that there's still another good reason to decouple
drandom from everything else: the point of setseed(), if it has any
at all, is to allow a repeatable sequence of drandom values to be
generated.  Without this patch, no such guarantee exists because of
the possibility of the backend making additional internal calls of
libc random().

			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