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

Fabien COELHO <coelho@cri.ensmp.fr>

From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-01-22T20:35:27Z
Lists: pgsql-hackers

Attachments

Hello Tom,

>>>> 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 seriously dislike this patch.  pgbench's random support is quite
>>> overengineered already IMO, and this proposes to add a whole batch of
>>> new code and new APIs to fix a very small bug.
>
>> My intention is rather to discuss postgres' PRNG, in passing. Full success
>> on this point:-)
>
> Our immediate problem is to fix a portability failure, which we need to
> back-patch into at least one released branch, ergo conservatism is
> warranted.

Sure, the patch I sent is definitely not for backpatching, it is for 
discussion.

>  I had in mind something more like the attached.

Yep.

I'm not too happy that it mixes API levels, and about the int/double/int 
path.

Attached an updated version which relies on pg_jrand48 instead. Also, as 
the pseudo-random state is fully controlled, seeded test results are 
deterministic so the expected value can be fully checked.

I did a few sanity tests which were all ok.

I think that this version is appropriate for backpatching. I also think 
that it would be appropriate to consider having a better PRNG to replace 
rand48 in a future release.

-- 
Fabien.

Commits

  1. Fix portability problem in pgbench.

  2. Avoid assuming that we know the spelling of getopt_long's error messages.