Horton

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

Noah Misch <noah@leadboat.com>

View thread View on postgr.es
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Joe Conway <mail@joeconway.com>, Peter Eisentraut <peter@eisentraut.org>, Alexander Korotkov <aekorotkov@gmail.com>, "Guo, Adam" <adamguo@amazon.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Nathan Bossart <nathandbossart@gmail.com>, Jim Mlodgenski <jimmy76@gmail.com>
Date: 2024-09-07T00:19:54Z
Lists: pgsql-hackers 
On Fri, Sep 06, 2024 at 07:37:09PM -0400, Tom Lane wrote:
> 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?

Those are disadvantages of some of the options.  I think it could be okay to
inject the mandatory upgrade here or just tell the user to update to 1.7
before attempting the upgrade (if not at 1.7, pg_upgrade would fail with an
error message to that effect).  Your counterproposal avoids the issue, and I'm
good with that design.

Commits

  1. pg_upgrade: Check for the expected error message in TAP tests.

  2. Fix a typo in 005_char_signedness.pl test.

  3. Add test 005_char_signedness.pl to meson.build.

  4. Fix an issue with index scan using pg_trgm due to char signedness on different architectures.

  5. pg_upgrade: Add --set-char-signedness to set the default char signedness of new cluster.

  6. pg_upgrade: Preserve default char signedness value from old cluster.

  7. pg_resetwal: Add --char-signedness option to change the default char signedness.

  8. Add default_char_signedness field to ControlFileData.

  9. Remove unneeded nbtree array preprocessing assert.