Re: Missing update of all_hasnulls in BRIN opclasses - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Missing update of all_hasnulls in BRIN opclasses
Date
Msg-id 201676.1682351186@sss.pgh.pa.us
Whole thread Raw
In response to Re: Missing update of all_hasnulls in BRIN opclasses  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Missing update of all_hasnulls in BRIN opclasses
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2023-Apr-23, Tomas Vondra wrote:
>> Both cases have a patch extending pageinspect to show the new flag, but
>> obviously we should commit that only in master. In backbranches it's
>> meant only to make testing easier.

> In backbranches, I think it should be reasonably easy to add a
> --1.7--1.7.1.sql file and set the default version to 1.7.1; that then
> enables us to have the functionality (and the tests) in older branches
> too.  If you just add a --1.X.1--1.12.sql version to each branch that's
> identical to that branch's current pageinspect version upgrade script,
> that would let us have working upgrade paths for all branches.  This is
> a bit laborious but straightforward enough.

"A bit laborious"?  That seems enormously out of proportion to the
benefit of putting this test case into back branches.  It will have
costs for end users too, not only us.  As an example, it would
unecessarily block some upgrade paths, if the upgraded-to installation
is slightly older and lacks the necessary --1.X.1--1.12 script.

> If you don't feel like adding that, I volunteer to add the necessary
> scripts to all branches after you commit the bugfix, and ensure that all
> upgrade paths work correctly.

I do not think this should happen at all, whether you're willing to
do the work or not.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: base backup vs. concurrent truncation
Next
From: Melanie Plageman
Date:
Subject: Re: could not extend file "base/5/3501" with FileFallocate(): Interrupted system call