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
|
| Список | 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 по дате отправления: