Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
Alexander Korotkov <aekorotkov@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tender Wang <tndrwang@gmail.com>, nicolas.maus@bertelsmann.de, pgsql-bugs@lists.postgresql.org
Date: 2024-11-08T08:47:35Z
Lists: pgsql-bugs
On Fri, Nov 8, 2024 at 7:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alexander Korotkov <aekorotkov@gmail.com> writes: > > So, yes, comparison using C-collation seems the most > > reasonable option. > > WFM. But I'm concerned that you couldn't build a test case > where the comparison fails. Seems like we need one, in view > of this bug having escaped detection for so long. AFAICS, the only use case of CheckIndexCompatible() is ALTER TYPE. In that case we only serialize and deserialize opclass options without any involvement of opclass or data type. So, with the current usage scenario CompareOpclassOptions() is only a paranoid check, but CheckIndexCompatible() has to do it due to its general semantic. Thus, if we have to build a test case where CompareOpclassOptions() fails, I guess we need to write a new module for src/test/modules, which would call CheckIndexCompatible() under different circumstances. ------ Regards, Alexander Korotkov Supabase
Commits
-
Fix arrays comparison in CompareOpclassOptions()
- 5411e821386c 13.18 landed
- 247e7647f598 14.15 landed
- 713b8546aba6 15.10 landed
- b242aba02666 16.6 landed
- a6fa869cfa4e 17.2 landed
- db22b900244d 18.0 landed