Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-01-18T17:56:22Z
Lists: pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes: >> all is explained here: >> https://man.openbsd.org/srandom >> Or at least most is explained there. > Yep. They try to be more serious than other systems about PRNG, which is > not bad in itself. > 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. regards, tom lane
Commits
-
Fix portability problem in pgbench.
- e6c3ba7fbfd5 12.0 landed
- 27d6bc68f98e 11.2 landed
-
Avoid assuming that we know the spelling of getopt_long's error messages.
- 434040159558 11.2 landed
- 251f57460f12 12.0 landed