Re: GiST operator class for bool
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, emre@hasegeli.com,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-11-08T01:24:22Z
Lists: pgsql-hackers
Attachments
- gistvalidate.patch (text/x-patch) patch
On 11/7/21 20:53, Tomas Vondra wrote:
> Hi,
>
> On 11/7/21 17:44, Tom Lane wrote:
>> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>>> Pushed, after adding some simple EXPLAIN to the regression test.
>>
>> skink is reporting that this has some valgrind issues [1].
>> I suspect sloppy conversion between bool and Datum, but
>> didn't go looking.
>>
>
> It's actually a bit worse than that :-( The opclass is somewhat confused
> about the type it should use for storage. The gbtree_ninfo struct says
> it's using gbtreekey4, the SQL script claims the params are gbtreekey8,
> and it should actually use gbtreekey2. Sorry for not noticing that.
>
> The attached patch fixes the valgrind error for me.
>
I've pushed the fix, hopefully that'll make skink happy.
What surprised me a bit is that the opclass used gbtreekey4 storage, the
equality support proc was defined as using gbtreekey8
FUNCTION 7 gbt_bool_same (gbtreekey8, gbtreekey8, internal),
yet the gistvalidate() did not report this. Turns out this is because
ok = check_amproc_signature(procform->amproc, INTERNALOID, false,
3, 3, opckeytype, opckeytype,
INTERNALOID);
i.e. with exact=false, so these type differences are ignored. Changing
it to true reports the issue (and no other issues in check-world).
But maybe there are reasons to keep using false?
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Commits
-
Add bool to btree_gist documentation
- 4c6145b514fa 15.0 landed
-
Fix gist_bool_ops to use gbtreekey2
- e2fbb883720a 15.0 landed
-
Add bool GiST opclass to btree_gist
- 57e3c5160b24 15.0 landed