Re: ltree_gist indexes broken after pg_upgrade from 12 to 13 - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: ltree_gist indexes broken after pg_upgrade from 12 to 13
Date
Msg-id 81574b33-360a-73b7-530a-dc314489a22b@enterprisedb.com
Whole thread Raw
In response to Re: ltree_gist indexes broken after pg_upgrade from 12 to 13  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: ltree_gist indexes broken after pg_upgrade from 12 to 13  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 2/24/22 23:13, Tomas Vondra wrote:
> 
> 
> On 2/24/22 23:06, Andres Freund wrote:
>> Hi,
>>
>> On 2022-02-24 22:15:20 +0100, Tomas Vondra wrote:
>>> After thinking about this I only see two options:
>>>
>>> 1) Don't apply the patch and tell everyone using ltree_gist they need to
>>> rebuild the index after pg_upgrade from 12 to 13+. The downside of this
>>> is larger indexes (because some tuples are 20B larger).
>>>
>>> 2) Apply the patch + tell those who already upgraded from 12 to rebuild
>>> ltree_gist indexes, because those might be broken due to new inserts.
>>>
>>>
>>> My opinion is to do (2), because at least those who'll upgrade later
>>> (which is a lot of people) will be fine without a rebuild. And it also
>>> makes the indexes a bit smaller, thanks to saving 20B.
>>
>> Won't 2) also break indexes created without a pg_upgrade? "already upgraded
>> from 12" sounds like it wouldn't but I don't see why?
>>
> 
> It will, unfortunately - that's why I wrote "upgrade" in that sentence.
> I should have been more explicit, sorry. But any new index tuples formed
> after starting the 13+ cluster are/may be corrupted.
> 

I wonder if we could check the index tuple length, and adjust the siglen
based on that, somehow ...


regards

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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: ltree_gist indexes broken after pg_upgrade from 12 to 13
Next
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Failed transaction statistics to measure the logical replication progress