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-08T20:29:20Z
Lists: pgsql-bugs
On Fri, Nov 8, 2024 at 4:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alexander Korotkov <aekorotkov@gmail.com> writes: > > On Fri, Nov 8, 2024 at 7:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> 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. > > OK. Well, let's settle for having a test case that at least runs > the code, even if only the success path is taken. > > With the release freeze bearing down on us, do you want to wait > till after the releases to fix this? It seems non-urgent given > how long it took for anyone to notice. Thank you for noticing this. I also think there is no urgency. And I will wait till the next release. ------ 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