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 20:29:20 |
Message-ID: | CAPpHfdvzCCN+2STR_CR_ijys4G1HmkW_ygsDegwXm-2xXHAy1w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Nov 8, 2024 at 4:49 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> > On Fri, Nov 8, 2024 at 7:10 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2024-11-08 20:40:39 | Re: HashAgg degenerate case |
Previous Message | Jeff Davis | 2024-11-08 18:48:12 | Re: HashAgg degenerate case |