On Wed, Apr 10, 2024 at 12:02 PM Tom Lane <tgl@sss.pgh.pa.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