Re: Issue with the PRNG used by Postgres

hi Robert,
We are using xoroshiro128 and not moved to the next state of art.
We did see a lot of low values as put in my last message.
-Parag

On Wed, Apr 10, 2024 at 9:37 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Apr 10, 2024 at 12:02 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > As I said to Parag, I see exactly no reason to believe that that's a
> > problem, unless it happens *a lot*, like hundreds of times in a row.
> > If it does, that's an RNG problem not s_lock's fault. Now, I'm not
> > going to say that xoroshiro can't potentially do that, because I've
> > not studied it. But if it is likely to do that, I'd think we'd
> > have noticed the nonrandomness in other ways.
>
> The blog post to which Parag linked includes this histogram as an
> example of a low-Hamming-weight situation:
>
> Reps | Value
> -----+--------
> 84 | 0x00
> 10 | 0x2d
> 6 | 0xa0
> 6 | 0x68
> 6 | 0x40
> 6 | 0x02
> 5 | 0x0b
> 4 | 0x05
> 4 | 0x01
> 3 | 0xe1
> 3 | 0x5a
> 3 | 0x41
> 3 | 0x20
> 3 | 0x16
>
> That's certainly a lot more zeroes than you'd like to see in 192 bytes
> of output, but it's not hundreds in a row either.
>
> Also, the blog post says "On the one hand, from a practical
> perspective, having vastly, vastly more close repeats than it should
> isn't likely to be an issue that users will ever detect in practice.
> Xoshiro256's large state space means it is too big to fail any
> statistical tests that look for close repeats." So your theory that we
> have a bug elsewhere in the code seems like it might be the real
> answer.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>