Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD
Date
Msg-id alpine.DEB.2.21.1901182257480.20734@lancre
Whole thread Raw
In response to Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
>> Maybe on OpenBSD pg should switch srandom to srandom_deterministic?
>
> Dunno.  I'm fairly annoyed by their idea that they're smarter than POSIX.
> 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.

-- 
Fabien.


pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: Alternative to \copy in psql modelled after \g
Next
From: Alvaro Herrera
Date:
Subject: Re: problems with foreign keys on partitioned tables