Re: Issue with the PRNG used by Postgres

Parag Paul <parag(dot)paul(at)gmail(dot)com> writes:
> So, if RNG generated 0.0000001 and cur_delay =1000.
> Result will be
> 1000 + int(1000*0.000001 + 5) = (int)(1000 + (0.1+.5)) = (int)1000.6 = 1000
> <-- back to the same value

Yes, with a sufficiently small RNG result, the sleep delay will not
increase that time through the loop. So what? It's supposed to be
a random amount of backoff, and I don't see why "random" shouldn't
occasionally include "zero". Why would requiring the delay to
increase improve matters at all?

Now, if the xoroshiro RNG is so bad that there's a strong likelihood
that multiple backends will sit on cur_delay = MIN_DELAY_USEC for
a long time, then yeah we could have a thundering-herd problem with
contention for the spinlock. You've provided no reason to think
that the probability of that is more than microscopic, though.
(If it is more than microscopic, then we are going to have
nonrandomness problems in a lot of other places, so I'd lean
towards revising the RNG not band-aiding s_lock. We've seen
nothing to suggest such problems, though.)

regards, tom lane