I wrote:
> Thomas Munro 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:
>
I wrote:
> Looking at this, I seem to remember that we considered doing exactly this
> awhile ago, but refrained because there was concern about depleting the
> system's reserve of entropy if we have a high backend spawn rate, and it
> didn't seem like there was a security reason to insist on
I wrote:
> Thomas Munro writes:
>> +1, but I wonder if just separating them is enough. Is our seeding
>> algorithm good enough for this new purpose? The initial seed is 100%
>> predictable to a logged in user (it's made from the backend PID and
>> backend start time, which we tell you), and not
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
Fabien COELHO writes:
>> but I don't feel a need for replacing the algorithm.
> Hmmm. Does it mean that you would veto any change, even if the speed
> concern is addressed (i.e. faster/not slower with better quality)?
Well, not veto exactly, but I'd be suspicious of it.
First, erand48 has
Hello again,
- lrand48 (48 bits state as 3 uint16)is 29 ops
(10 =, 8 *, 7 +, 4 >>)
- xoshiro256** (256 bits states as 4 uint64) is 24 ops (18 if rot in hw)
8 =, 2 *, 2 +, 5 <<, 5 ^, 2 |
Small benchmark on my laptop with gcc-7.3 -O3:
- pg_lrand48 takes 4.0 seconds to generate 1
On 12/26/18 7:45 PM, Tom Lane 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.
FYI I picked the idea from auto_explain. Maybe we will have to change
- lrand48 (48 bits state as 3 uint16)is 29 ops
(10 =, 8 *, 7 +, 4 >>)
- xoshiro256** (256 bits states as 4 uint64) is 24 ops (18 if rot in hw)
8 =, 2 *, 2 +, 5 <<, 5 ^, 2 |
See http://vigna.di.unimi.it/xorshift/
Small benchmark on my laptop with gcc-7.3 -O3:
- pg_lrand48
About costs, not counting array accesses:
- lrand48 (48 bits state as 3 uint16)is 29 ops
(10 =, 8 *, 7 +, 4 >>)
- xorshift+ (128 bits state as 2 uint64) is 13 ops
( 5 =, 0 *, 1 +, 3 >>, 4 ^)
- xororshift128+ (idem) is 17 ops
( 6 =, 0 *, 1 +, 5 >>, 3 ^, 2
Hello Tom,
Another idea, which would be a lot less prone to breakage by
add-on code, is to change drandom() and setseed() to themselves
use pg_erand48() with a private seed.
The pg_erand48 code looks like crumbs from the 70's optimized for 16 bits
architectures (which it is probably not,
Fabien COELHO writes:
>> Another idea, which would be a lot less prone to breakage by
>> add-on code, is to change drandom() and setseed() to themselves
>> use pg_erand48() with a private seed.
> The pg_erand48 code looks like crumbs from the 70's optimized for 16 bits
> architectures (which it
I wrote:
> Peter Geoghegan writes:
>> We're already making fairly broad assumptions about our having control
>> of the backend's PRNG state within InitProcessGlobals(). How should
>> this affect the new drandom()/setseed() private state, if at all?
> I would think that InitProcessGlobals would
Thomas Munro writes:
> On Thu, Dec 27, 2018 at 3:55 PM Peter Geoghegan wrote:
>> On Wed, Dec 26, 2018 at 6:39 PM Tom Lane wrote:
>>> The point here is not to be cryptographically strong at every single
>>> place where the backend might want a random number; I think we're
>>> all agreed that we
Peter Geoghegan writes:
> On Wed, Dec 26, 2018 at 6:39 PM Tom Lane wrote:
>> Now, we could probably fix that with some less intrusive patch than
>> #define'ing random() --- in particular, if we give drandom and setseed
>> their own private PRNG state, we've really fixed the security exposure
>>
On Thu, Dec 27, 2018 at 3:55 PM Peter Geoghegan wrote:
> On Wed, Dec 26, 2018 at 6:39 PM Tom Lane wrote:
> > The point here is not to be cryptographically strong at every single
> > place where the backend might want a random number; I think we're
> > all agreed that we don't need that. To me,
On Wed, Dec 26, 2018 at 6:39 PM Tom Lane wrote:
> The point here is not to be cryptographically strong at every single
> place where the backend might want a random number; I think we're
> all agreed that we don't need that. To me, the point is to ensure that
> the user-accessible random
On Wed, Dec 26, 2018 at 08:46:25PM -0500, Tom Lane wrote:
> 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
Michael Paquier 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
>>
On Wed, Dec 26, 2018 at 1:21 PM Tom Lane wrote:
> One thing we'd have to think about if we want to take this seriously
> is whether a process-wide PRNG state is really adequate; if you're
> trying to make a particular call site be deterministic, you'd likely
> wish it weren't interfered with by
Peter Geoghegan writes:
> On Wed, Dec 26, 2018 at 12:19 PM Tom Lane wrote:
>> Replacing random() might actually make that easier not harder, since
>> we'd have more control over what happens when.
> That does seem useful. I'm in favor. But why does the function to seed
> the internal PRNG have
On Wed, Dec 26, 2018 at 12:19 PM Tom Lane wrote:
> Replacing random() might actually make that easier not harder, since
> we'd have more control over what happens when.
That does seem useful. I'm in favor. But why does the function to seed
the internal PRNG have to be loadable? Can't it just be
Peter Geoghegan writes:
> I'm beginning to think that the technique that I came up with to make
> "getting tired" deterministic ought to be supporting as a debugging
> option if we're to do away with internal use of the generic/seedable
> backend PRNG.
I have no objection to providing such a
Peter Geoghegan writes:
> On Wed, Dec 26, 2018 at 10:45 AM Tom Lane 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
On Wed, Dec 26, 2018 at 10:45 AM Tom Lane 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
Alvaro Herrera writes:
> Thanks! I pushed this with two changes -- one was to reword the docs a
> bit more, and the other was to compute in_sample only if it's going to
> be used (when exceeded is true). I hope this won't upset any compilers ...
> I wonder if there's any sensible way to verify
25 matches
Mail list logo
