Re: [PATCH] Don't block HOT update by BRIN index

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Josef Šimánek <josef(dot)simanek(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Don't block HOT update by BRIN index
Date: 2021-12-11 04:44:22
Message-ID: b10714af-ab5e-2c10-1786-383dbb1747a4@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/6/21 02:47, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-12-11 04:55:36 Re: Non-superuser subscription owners
Previous Message Thomas Munro 2021-12-11 04:41:34 Re: Add client connection check during the execution of the query