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

  1. Fix arrays comparison in CompareOpclassOptions()