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

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-22 20:35:27
Message-ID: alpine.DEB.2.21.1901222007100.16643@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

Attachment Content-Type Size
pgbench-prng-3.patch text/x-diff 5.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-01-22 20:38:32 Re: Refactoring the checkpointer's fsync request queue
Previous Message Andrew Gierth 2019-01-22 20:32:22 Re: Strange query behaviour