On Fri, Dec 15, 2023 at 04:00:01PM +0300, Alexander Lakhin wrote:
> 13.12.2023 21:00, Alexander Lakhin wrote:
>> 13.12.2023 17:18, Michael Paquier wrote:
>> > On Wed, Dec 13, 2023 at 09:00:01AM +0000, PG Bug reporting form wrote:
>> > > This anomaly can be observed since 8b08f7d48 from 2018-01-19, but IMO the
>> > > culprit is e759854a0 from 2017-02-03, which introduced the following
>> > > asymmetry in pgstatindex.c:
>> > > if (!IS_INDEX(rel) || !IS_BTREE(rel))
>> > > if (!IS_INDEX(rel) || !IS_GIN(rel))
>> > > But:
>> > > if (!IS_HASH(rel))
>> > Fun, let's fix that. Would you like to write a patch?
>>
>> Yes, please look at the attached,
Thanks. The one for pgstattuple has been applied down to 12 as of
a8dd62ef4959.
> Looking around, I found the similar index_open() usage within pageinspect,
> function hash_bitmap_info():
> CREATE EXTENSION pageinspect;
> CREATE TABLE t (a int, b int[], c int) PARTITION BY RANGE (a);
> CREATE INDEX c_idx ON t USING hash(c);
> SELECT hash_bitmap_info('c_idx'::regclass, 1);
>
> Leads to:
> TRAP: failed Assert("false"), File: "bufmgr.c", Line: 3606, PID: 3984550
Right.
> I'm inclined to leave index_open() there for the internal consistency
> inside pageinspect, and to use the same condition as in
> bt_index_block_validate(), which called by functions bt_page_stats(...),
> bt_multi_page_stats(...), bt_page_items(relname text, blkno bigint).
>
> Functions for other index types, brin/gin/gist, don't read the index,
> instead they receive a page as input.
Not sure to agree on that. It seems a bit strange to bump on a
different error when using a partitioned index or a relkind not
allowed by index_open(). And this is after looking at the pgstattuple
code.
At the end, I've switched to relation_open() for this one, added a
test and applied the second patch as of 208470136421. I've checked
the rest and yes, it looks like there are no other holes like the
ones you have reported for the contrib modules when it comes to index
manipulations.
--
Michael