From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD |
Date: | 2019-01-18 22:01:07 |
Message-ID: | alpine.DEB.2.21.1901182257480.20734@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-01-18 22:16:33 | Re: problems with foreign keys on partitioned tables |
Previous Message | Daniel Verite | 2019-01-18 21:31:30 | Re: Alternative to \copy in psql modelled after \g |