On 1/19/23 11:01, Tom Lane wrote:
Andrey Lepikhov <a.lepik...@postgrespro.ru> writes:
On 1/9/23 23:52, Tom Lane wrote:
BTW, if this does bring the probability of failure down to the
one-in-a-billion range, I think we could also nuke the whole
"ignore:" business, simplifying pg_regress and allowing the
random test to be run in parallel with others.
We have used the pg_sleep() function to interrupt a query at certain
execution phase. But on some platforms, especially in containers, the
query can vary execution time in so widely that the pg_sleep() timeout,
required to get rid of dependency on a query execution time, has become
unacceptable. So, the "ignore" option was the best choice.
But does such a test have any actual value? If your test infrastructure
ignores the result, what makes you think you'd notice if the test did
indeed detect a problem?
Yes, it is good to catch SEGFAULTs and assertions which may be frequent
because of a logic complexity in the case of timeouts.
I think "ignore:" was a kluge we put in twenty-plus years ago when our
testing standards were a lot lower, and it's way past time we got
rid of it.
Ok, I will try to invent alternative way for deep (and stable) testing
of timeouts. Thank you for the answer.
--
Regards
Andrey Lepikhov
Postgres Professional
