From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Adrien Nayrat <adrien.nayrat@anayrat.info>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Vik Fearing <vik.fearing@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: David Rowley <david.rowley@2ndquadrant.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: random() (was Re: New GUC to sample log queries)
Date: Wed, 26 Dec 2018 14:31:06 -0500
Message-ID: <5659.1545852666@sss.pgh.pa.us> (raw)
In-Reply-To: <CAH2-Wzk1Wa4TcrdOQv=eknY_NWyr2bTKf3rFtWPu06-V6LhE6A@mail.gmail.com>
References: <20181129214850.kiq6mvofsgplqjdr@alvherre.pgsql>
<3859.1545849900@sss.pgh.pa.us>
<CAH2-Wzk1Wa4TcrdOQv=eknY_NWyr2bTKf3rFtWPu06-V6LhE6A@mail.gmail.com>
Peter Geoghegan <pg@bowt.ie> writes:
> On Wed, Dec 26, 2018 at 10:45 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I wonder whether we should establish a project policy to avoid use
>> of random() for internal purposes, ie try to get to a point where
>> drandom() is the only caller in the backend. 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().
> I've used setseed() to make nbtree's "getting tired" behavior
> deterministic for specific test cases I've developed -- the random()
> choice of whether to split a page full of duplicates, or continue
> right in search of free space becomes predictable. I've used this to
> determine whether my nbtree patch's pg_upgrade'd indexes have
> precisely the same behavior as v3 indexes on the master branch
> (precisely the same in terms of the structure of the final index
> following a bulk load).
TBH, I'd call it a bug --- maybe even a low-grade security hazard
--- that it's possible to affect that from user level.
In fact, contemplating that for a bit: it is possible, as things
stand in HEAD, for a user to control which of his statements will
get logged if the DBA has enabled log_statement_sample_rate.
It doesn't take a lot of creativity to think of ways to abuse that.
So maybe Coverity had the right idea to start with.
There might well be debugging value in affecting internal PRNG usages,
but let's please not think it's a good idea that that's trivially
reachable from SQL.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pg@bowt.ie, alvherre@2ndquadrant.com, adrien.nayrat@anayrat.info, thomas.munro@enterprisedb.com, 9erthalion6@gmail.com, tomas.vondra@2ndquadrant.com, vik.fearing@2ndquadrant.com, robertmhaas@gmail.com, michael@paquier.xyz, david.rowley@2ndquadrant.com
Subject: Re: random() (was Re: New GUC to sample log queries)
In-Reply-To: <5659.1545852666@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox