On 12/6/21 02:47, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> On 12/5/21 21:16, Tom Lane wrote:
>>> Oh, geez. *Please* let us not add another regression failure mode
>>> like the ones that afflict stats.sql. We do not need a doubling
>>> of that failure rate. I suggest just removing this test.
>
>> Whooops. Agreed, I'll get rid of that test.
>
> Another idea, perhaps, is to shove that test into stats.sql,
> where people would know to ignore it? (Actually, I've thought
> more than once that we should mark stats.sql as ignorable
> in the schedule ...)
>
Yep. I've moved the test to stats.sql - that seems better than just
ditching it, because we're experimenting with maybe relaxing the HOT
rules for BRIN a bit further and not having tests for that would be
unfortunate.
I haven't marked the test as ignorable. I wonder if we should make that
customizable, so that some animals (like serinus, which fails because of
stats.sql from time to time) could run ignore it. But if it fails
elsewhere it would still be considered a proper failure.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
