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)postgreSQL(dot)org> |
Subject: | Re: pgbench regression test failure |
Date: | 2017-09-12 18:00:56 |
Message-ID: | alpine.DEB.2.20.1709121955450.30961@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>> Apparently, one of the threads ran 3 transactions where the test script
>>> expects it to run at most 2. Is this a pgbench bug, or is the test
>>> being overoptimistic about how exact the "-T 2" cutoff is?
>
>> Probably both? It seems that cutting off on time is not a precise science,
>> so I suggest to accept 1, 2 and 3 lines, see attached.
>
> Before I'd deciphered the test output fully, I was actually guessing that
> the problem was the opposite, namely too few lines.
The test was waiting for betwen 1 and 2 lines, so I assumed that the 3
should the number of lines found.
> Isn't it possible that some thread is slow enough to start up that it
> doesn't get to run any transactions? IOW, do we need to allow 0 to 3
> lines?
By definition, parallelism induces non determinism. When I put 2 seconds,
the intention was that I would get a non empty trace with a "every second"
aggregation. I would rather take a longer test rather than allowing an
empty file: the point is to check that something is generated, but
avoiding a longer test is desirable. So I would suggest to stick to
between 1 and 3, and if it fails then maybe add one second...
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-09-12 18:12:16 | Re: pgbench regression test failure |
Previous Message | Hadi Moshayedi | 2017-09-12 17:40:43 | [PATCH] Call RelationDropStorage() for broader range of object drops. |