Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
Tender Wang <tndrwang@gmail.com>
From: Tender Wang <tndrwang@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, nicolas.maus@bertelsmann.de, pgsql-bugs@lists.postgresql.org
Date: 2024-11-08T02:26:32Z
Lists: 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
Commits
-
Fix arrays comparison in CompareOpclassOptions()
- 5411e821386c 13.18 landed
- 247e7647f598 14.15 landed
- 713b8546aba6 15.10 landed
- b242aba02666 16.6 landed
- a6fa869cfa4e 17.2 landed
- db22b900244d 18.0 landed