Re: pgsql: Remove pgbench "progress" test pending solution of its timing is

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Remove pgbench "progress" test pending solution of its timing is
Date: 2017-09-23 19:30:13
Message-ID: alpine.DEB.2.20.1709232121140.4999@lancre
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers


>> If the test must run even when postgres doesn't, it is a little bit
>> hard as a starting assumption for a benchmarking tool:-(
>
> I'm unsure what the point of this is. It's not like we discussing
> removing pgbench, we're talking about an unreliable test.

My sentence was probably not very clear.

I just meant that devising a coverage test which does not fail when the
benchmarking tool is not able to run because of load/valgrind/... is kind
of hard.

Anything even loosely related to time, here having a few simple SELECT
transactions over 2 seconds and a few printf into a file or stdout every
second, can always fail if conditions are bad enough.

So this means somehow giving up on coverage, because of one host which can
fail under very unusual testing conditions once in a while.

I would prefer to keep the test and have a warning instead, something
like "ok, although a test which is allowed to rarely fail failed", but at
least the feature are tested most of the time.

Sigh.

--
Fabien.

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-09-23 20:01:51 Re: pgsql: Remove pgbench "progress" test pending solution of its timing is
Previous Message Tom Lane 2017-09-23 19:16:57 pgsql: ... and the very same bug in publicationListToArray().