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

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: 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@2ndquadrant.com, Robert Haas <robertmhaas@gmail.com>, David Rowley <david.rowley@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-12-27T01:46:25Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Dec 26, 2018 at 01:45:00PM -0500, Tom Lane wrote:
>> A quick grep says that there's a dozen or so callers, so this patch
>> certainly isn't the only offender ... but should we make an effort
>> to convert them all to use, say, pg_erand48()?  I think all the
>> existing callers  could happily share a process-wide random state,
>> so we could make a wrapper that's no harder to use than random().

> Another possibility would be to extend a bit more the use of
> pg_strong_random(), though it is designed to really be used in cases
> like authentication where the random bytes are strong for
> cryptography.  pg_erand48() would be a good step forward.

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 ...

One thing I was wondering is if we should try to enforce a policy
like this by putting, say,

#define random() pg_random()

into port.h or so.  That would have the advantages of not having to touch
any existing calls and not having to worry too much about future patches
breaking the policy.  On the other hand, it's conceivable that third-party
extensions might get annoyed with us for hijacking a libc function.
Thoughts?

			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