Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Date
Msg-id 2393003.1725665829@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation  (Noah Misch <noah@leadboat.com>)
Responses Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Fri, Sep 06, 2024 at 06:36:53PM -0400, Tom Lane wrote:
>> I feel like all of these are leaning heavily on users to get it right,

> What do you have in mind?  I see things for the pg_upgrade implementation to
> get right, but I don't see things for pg_upgrade users to get right.

Well, yeah, if you are willing to put pg_upgrade in charge of
executing ALTER EXTENSION UPDATE, then that would be a reasonably
omission-proof path.  But we have always intended the pg_upgrade
process to *not* auto-update extensions, so I'm concerned about
the potential side-effects of drilling a hole in that policy.
As an example: even if we ensure that pg_trgm 1.6 to 1.7 is totally
transparent except for this fix, what happens if the user's old
database is still on some pre-1.6 version?  Is it okay to force an
update that includes feature upgrades?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Next
From: Noah Misch
Date:
Subject: Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation