Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tender Wang <tndrwang(at)gmail(dot)com>, nicolas(dot)maus(at)bertelsmann(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
Date: 2024-11-08 08:47:35
Message-ID: CAPpHfdsH6ACTzcBAs_YC+UzFgjCWTzhNpaAOxssEJ75jH5xVXw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Nov 8, 2024 at 7:10 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <aekorotkov(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bastien Roucariès 2024-11-08 08:56:45 Re: Detection of hadware feature => please do not use signal
Previous Message David Pavlíček 2024-11-08 07:51:36 Re: BUG #18694: DISCARD ALL does not reset execution counters for plpgsql functions