Re: GIN pageinspect support for entry tree and posting tree - Mailing list pgsql-hackers

From Roman Khapov
Subject Re: GIN pageinspect support for entry tree and posting tree
Date
Msg-id 0A0E3993-7617-48EA-8555-6C1907C147E5@yandex-team.ru
Whole thread Raw
In response to Re: GIN pageinspect support for entry tree and posting tree  (Kirill Reshke <reshkekirill@gmail.com>)
Responses Re: GIN pageinspect support for entry tree and posting tree
List pgsql-hackers
> Hi! Thank you 🙏 for your effort. 0003 looks good to me
>
> --
> Best regards,
> Kirill Reshke

Hi! Thanks for the patch!

I'v been reviewing your patch, and noticed there are some code logic
that handles NULL values, but tests doesn't cover this scenarios.

So, I added simple line at contrib/pageinspect/sql/gin.sql:

 INSERT INTO test1 VALUES (1, ARRAY[11, 111], ARRAY['a', 'b', 'c']);
+INSERT INTO test1 VALUES (1, ARRAY[NULL, 222], ARRAY['d', NULL]);
 CREATE INDEX test1_y_idx ON test1 USING gin (y) WITH (fastupdate = off);

And got unexpected result...
As far as I understand, we shouldn't get error for the whole
gin_entrypage_items executions when there are NULL-values columns at index key, but the
output contains only the next error:

 SELECT * FROM gin_entrypage_items(get_raw_page('test1_y_idx', 1), 'test1_y_idx'::regclass);
--[ RECORD 1 ]--------------
-itemoffset | 1
-downlink   | (2147483664,1)
-tids       | {"(0,1)"}
-keys       | y=11
--[ RECORD 2 ]--------------
-itemoffset | 2
-downlink   | (2147483664,1)
-tids       | {"(0,1)"}
-keys       | y=111
-
+ERROR:  invalid gin entry page tuple at offset 4

Is the NULL values handle correct?

--
Best regards,
Roman Khapov




pgsql-hackers by date:

Previous
From: Ilia Evdokimov
Date:
Subject: Re: Hash-based MCV matching for large IN-lists
Next
From: Amit Kapila
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication