From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joe Conway <mail(at)joeconway(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, "Guo, Adam" <adamguo(at)amazon(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Jim Mlodgenski <jimmy76(at)gmail(dot)com> |
Subject: | Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation |
Date: | 2025-02-20 22:07:54 |
Message-ID: | 20250220220754.e6.nmisch@google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 19, 2025 at 10:48:29AM -0800, Masahiko Sawada wrote:
> Thank you for reviewing the patches. I've fixed these issues and
> attached the updated patches.
Looks good.
> I have one question about the 0001 patch; since we add
> 'default_char_signedness' field to ControlFileData do we need to bump
> PG_CONTROL_VERSION? We have comments about bumping PG_CONTROL_VERSION
> when changing CheckPoint struct or DBState enum so it seems likely but
> I'd like to confirm just in case that we need to bump
> PG_CONTROL_VERSION also when changing ControlFileData.
Yes. (I'm not aware of value we get from having distinct control file version
and catalog version, but we do have both.)
> If we need, can
> we bump it to 1800? or 1701?
I'd do 1800. The pattern seems to be to bump to 1800 for the first pg_control
change of the v18 cycle, then 1801, then 1802 for the third change of the
cycle. That's based on this history:
git log -U0 -p src/include/catalog/pg_control.h | grep -E '^(Date|\+#define PG_CONTROL_VERSION)'
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2025-02-20 22:17:10 | Re: BitmapHeapScan streaming read user and prelim refactoring |
Previous Message | Alena Rybakina | 2025-02-20 21:09:27 | Re: Replace IN VALUES with ANY in WHERE clauses during optimization |