From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Tender Wang <tndrwang@gmail.com>
Cc: nicolas.maus@bertelsmann.de
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
Date: Fri, 08 Nov 2024 00:10:54 -0500
Message-ID: <3557257.1731042654@sss.pgh.pa.us> (raw)
In-Reply-To: <CAPpHfdtZ2a=1FbZXUeEbx0i-avsQb=6UE9Kg8eTLoQzt3KaY0w@mail.gmail.com>
References: <18692-72ea398df3ec6712@postgresql.org>
<3261639.1730912933@sss.pgh.pa.us>
<CAPpHfdsedeW4qiF_Ky88u=+0Ep7ZGH5yBd47a-rueQ2_jh3Dhw@mail.gmail.com>
<CAHewXN=eBAk2wMn00CCYqcqC-1UtCHBMxr0nREUp_Ch8XYSQEg@mail.gmail.com>
<CAPpHfdvc1C4Q9LQ-x9SarnM14UcaqxvursrZWrQbF8r2CT9ghg@mail.gmail.com>
<3534898.1731031548@sss.pgh.pa.us>
<CAPpHfdtZ2a=1FbZXUeEbx0i-avsQb=6UE9Kg8eTLoQzt3KaY0w@mail.gmail.com>
Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Fri, Nov 8, 2024 at 4:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think this is nonsense. What about toasted datums, or even
>> just short-header ones?
> You are correct. I quickly skim trough the sources and didn't find a
> function which compares detoasted contents of Datums excluding
> headers.
Right, there isn't one AFAIK. For context, datumIsEqual() is mainly
meant to support cases such as comparison of Const nodes in equal(),
where
a) false match is unacceptable, but false no-match will at worst
cause some performance loss;
b) the two inputs have probably come through similar paths (eg,
both are fresh from the parser, or both were on-disk), so that
any toasting effects will be the same.
Also
c) for many of the callers, it'd be unsafe to perform disk
access to allow accurate comparison of out-of-line values.
Problem (a) would be all right for this case, and (c) too,
but not so much (b).
You can certainly imagine writing a more aggressive routine
that can cope with detoasting, but I don't think we've yet
found a case where that seemed worth the trouble. Partial
solutions such as "cope with short-header but not compressed
values" have even narrower possible use-cases.
> So, yes, comparison using C-collation seems the most
> reasonable option.
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.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, aekorotkov@gmail.com, tndrwang@gmail.com, nicolas.maus@bertelsmann.de, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length
In-Reply-To: <3557257.1731042654@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox