Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD

Hello Tom,

>>> Maybe on OpenBSD pg should switch srandom to srandom_deterministic?
>> 
>> Dunno.  I'm fairly annoyed by their idea that they're smarter than POSIX.

Hmmm. I'm afraid that is not that hard.

>> However, for most of our uses of srandom, this behavior isn't awful;
>> it's only pgbench that has an expectation that the platform random()
>> can be made to behave deterministically.  And TBH I think that's just
>> an expectation that's going to bite us.
>> 
>> I'd suggest that maybe we should get rid of the use of both random()
>> and srandom() in pgbench, and go over to letting set_random_seed()
>> fill the pg_erand48 state directly.  In the integer-seed case you
>> could use something equivalent to pg_srand48.  (In the other cases
>> probably you could do better, certainly the strong-random case could
>> just fill all 6 bytes directly.)  That would get us to a place where
>> the behavior of --random-seed=N is not only deterministic but
>> platform-independent, which seems like an improvement.
>
> That's a point. Althought I'm not found of round48, indeed having something 
> platform independent for testing makes definite sense.
>
> I'll look into it.

Here is a POC which defines an internal interface for a PRNG, and use it 
within pgbench, with several possible implementations which default to 
rand48.

I must admit that I have a grudge against standard rand48:

  - it is a known poor PRNG which was designed at a time when LCG where
    basically the only low cost PRNG available. Newer designs were very
    recent when the standard was set.
  - it is a LCG, i.e. its low bits cycle quickly, so should not be used.
  - so the 48 bit state size is relevant for generating 32 bits ints
    and floats.
  - however it eis used to generate more bits...
  - the double function uses all 48 bits, whereas 52 need to be filled...
  - and it is used to generate integers, which means that for large range
    some values are inaccessible.
  - 3 * 16 bits integers state looks silly on 32/64 bit architectures.
  - ...

Given that postgres needs doubles (52 bits mantissa) and possibly 64 bits 
integers, IMO the internal state should be 64 bits as a bare minimum, 
which anyway is also the minimal bite on 64 bit architectures, which is 
what is encoutered in practice.

-- 
Fabien.