Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
От | Alexander Korotkov |
---|---|
Тема | Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length |
Дата | |
Msg-id | CAPpHfdvzCCN+2STR_CR_ijys4G1HmkW_ygsDegwXm-2xXHAy1w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-bugs по дате отправления: