Horton

Re: Missing update of all_hasnulls in BRIN opclasses

Tomas Vondra <tomas.vondra@enterprisedb.com>

View thread View on postgr.es
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-04-24T21:10:55Z
Lists: pgsql-hackers 

On 4/24/23 23:05, Tomas Vondra wrote:
> 
> 
> On 4/24/23 17:46, Tom Lane wrote:
>> 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.
>>
> 
> Why would that block the upgrade? Presumably we'd add two upgrade
> scripts in the master, to allow upgrade both from 1.X and 1.X.1.
> 

D'oh! I just realized I misunderstood the issue. Yes, if the target
version is missing the new script, that won't work. I'm not sure how
likely that is - in my experience people refresh versions at the same
time - but it's certainly an assumption we shouldn't do, I guess.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Show empty BRIN ranges in brin_page_items

  2. Fix handling of empty ranges and NULLs in BRIN

  3. Fix handling of NULLs when merging BRIN summaries

  4. Move IS [NOT] NULL handling from BRIN support functions