| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| 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 02:05:48 |
| Message-ID: | 3534898.1731031548@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> On Thu, Nov 7, 2024 at 8:47 AM Tender Wang <tndrwang(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2024-11-08 02:22:42 | Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length |
| Previous Message | Mineharu Takahara | 2024-11-08 00:17:30 | Re: Suboptimal query plans for BETWEEN SYMMETRIC operations |