Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
Date
Msg-id 3534898.1731031548@sss.pgh.pa.us
Whole thread Raw
In response to BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length  (PG Bug reporting form <noreply@postgresql.org>)
List pgsql-bugs
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.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Mineharu Takahara
Date:
Subject: Re: Suboptimal query plans for BETWEEN SYMMETRIC operations
Next
From: Tender Wang
Date:
Subject: Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length