Re: [HACKERS] pgbench regression test failure
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] pgbench regression test failure |
Дата | |
Msg-id | alpine.DEB.2.20.1709131132260.20876@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] pgbench regression test failure (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] pgbench regression test failure
|
Список | pgsql-hackers |
>>> I have a serious, serious dislike for tests that seem to work until >>> they're run on a heavily loaded machine. > >> I'm not that sure the error message was because of that. > > No, this particular failure (probably) wasn't. But now that I've realized > that this test case is timing-sensitive, I'm worried about what will > happen when it's run on a sufficiently slow or loaded machine. > >>> I would not necessarily object to doing something in the code that >>> would guarantee that, though. > >> Hmmm. Interesting point. > > It could be as simple as putting the check-for-done at the bottom of the > loop not the top, perhaps. I agree that it is best if tests should work in all reasonable conditions, including a somehow overloaded host... I'm going to think about it, but I'm not sure of the best approach. In the mean time, ISTM that the issue has not been encountered (yet), so this is not a pressing issue. Maybe under -T > --aggregate-interval pgbench could go on over the limit if the log file has not been written at all, but that would be some kind of kludge for this specific test... Note that to get test coverage for -T and have to assume that maybe a loaded host would not be able to generate just a one line log every second during that time is kind of a hard assumption... Maybe some test could be "warnings", i.e. it could be acceptable to accept a failure once in a while in specific conditions, if this is rare enough and documented. ISTM that there is such a test for random output. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: