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