Re: GIN pageinspect support for entry tree and posting tree

From: Roman Khapov <rkhapov(at)yandex-team(dot)ru>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: Japin Li <japinli(at)hotmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GIN pageinspect support for entry tree and posting tree
Date: 2026-01-14 10:26:00
Message-ID: 0A0E3993-7617-48EA-8555-6C1907C147E5@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-01-14 10:29:31 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Ilia Evdokimov 2026-01-14 10:19:36 Re: Hash-based MCV matching for large IN-lists