Re: pgbench test failing on 14beta1 on Debian/i386

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: pgbench test failing on 14beta1 on Debian/i386
Дата
Msg-id CAEZATCWcT9Qq5B4CTcNCG2kZ+j-JMGv8y5uRY1+UGdjVSV-NxQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgbench test failing on 14beta1 on Debian/i386  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: pgbench test failing on 14beta1 on Debian/i386  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
On Wed, 19 May 2021 at 11:32, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>
> >> Or, (3) remove this test?  I am not quite sure what there is to gain
> >> with this extra test considering all the other tests with permute()
> >> already present in this script.
> >
> > Yes, I think removing the test is the best option. It was originally
> > added because there was a separate code path for larger permutation
> > sizes that needed testing, but that's no longer the case so the test
> > really isn't adding anything.
>
> Hmmm…
>
> It is the one test which worked in actually detecting an issue, so I would
> not say that it is not adding anything, on the contrary, it did prove its
> value! The permute function is expected to be deterministic on different
> platforms and architectures, and it is not.
>

In fact what it demonstrates is that the results from permute(), like
all the other pgbench random functions, will vary by platform for
sufficiently large size parameters.

> I'd agree with a two phases approach: drop the test in the short term and
> deal with the PRNG later. I'm sooooo unhappy with this 48 bit PRNG that I
> may be motivated enough to attempt to replace it, or at least add a better
> (faster?? larger state?? same/better quality?) alternative.
>

I don't necessarily have a problem with that provided the replacement
is well-chosen and has a proven track record (i.e., let's not invent
our own PRNG).

For now though, I'll go remove the test.

Regards,
Dean



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Incorrect usage of strtol, atoi for non-numeric junk inputs