Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
От | Tender Wang |
---|---|
Тема | Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length |
Дата | |
Msg-id | CAHewXNmmQ9wYFFtjE6Bh-xf_45NZQai=gMD7hc8qiHs8pNDisQ@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
Alexander Korotkov <aekorotkov@gmail.com> 于2024年11月8日周五 10:22写道:
On Fri, Nov 8, 2024 at 4:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alexander Korotkov <aekorotkov@gmail.com> writes:
> > On Thu, Nov 7, 2024 at 8:47 AM Tender Wang <tndrwang@gmail.com> wrote:
> >> Based on Tom's analysis, I provide a POC patch. I'm not sure if it is right
> >> to use DEFAULT_COLLATION_OID in the patch.
>
> > Thank you. But I'm not sure about DEFAULT_COLLATION_OID.
>
> I don't quite trust that either. But since we only care about
> equality, wouldn't it be OK to use C_COLLATION_OID?
>
> > Therefore, we can compare two text[] just with datumIsEqual().
> > Attached patch implements this.
>
> I think this is nonsense. What about toasted datums, or even
> just short-header ones? The one coming from an on-disk tuple
> is pretty likely to be short-header for plausible sizes of
> the options, but the one we just constructed in memory will
> not be.
You are correct. I quickly skim trough the sources and didn't find a
function which compares detoasted contents of Datums excluding
headers. So, yes, comparison using C-collation seems the most
reasonable option.
No objection from me.
Thanks,
Tender Wang
В списке pgsql-bugs по дате отправления: