Thread: BUG #17815: Server crashes on executing gist_page_items() in pageinspect extension

The following bug has been logged on the website:

Bug reference:      17815
Logged by:          Egor Chindyaskin
Email address:      kyzevan23@mail.ru
PostgreSQL version: 15.2
Operating system:   Ubuntu 22.04
Description:

When executing the following query:

CREATE EXTENSION pageinspect;

CREATE TABLE test_gist (p point, t text);
CREATE INDEX test_gist_idx ON test_gist USING gist (p);
CREATE INDEX test_gist_btree on test_gist(t);
SELECT gist_page_items(get_raw_page('test_gist_btree', 0),
'test_gist_idx');

DROP EXTENSION pageinspect;

I got server crash with the following backtrace:

Core was generated by `postgres: egorchin egorchin [local] SELECT
        '.
Program terminated with signal SIGABRT, Aborted.
#0  __pthread_kill_implementation (no_tid=0, signo=6,
threadid=139699942591360) at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6,
threadid=139699942591360) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=139699942591360) at
./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=139699942591360, signo=signo@entry=6) at
./nptl/pthread_kill.c:89
#3  0x00007f0e6d442476 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#4  0x00007f0e6d4287f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x0000562438c9e2fc in ExceptionalCondition (conditionName=0x7f0e6d656c78
"ItemIdHasStorage(itemId)", fileName=0x7f0e6d656be0
"../../src/include/storage/bufpage.h", lineNumber=355)
    at assert.c:66
#6  0x00007f0e6d64f2cd in PageGetItem (page=0x5624395f3148 "",
itemId=0x5624395f3164) at ../../src/include/storage/bufpage.h:355
#7  0x00007f0e6d65006e in gist_page_items (fcinfo=0x562439605db0) at
gistfuncs.c:254
#8  0x000056243881cab0 in ExecMakeFunctionResultSet (fcache=0x562439605150,
econtext=0x562439604750, argContext=0x5624395fd180, isNull=0x5624396050e0,
isDone=0x562439605138)
    at execSRF.c:625
#9  0x000056243885e18f in ExecProjectSRF (node=0x562439604640,
continuing=false) at nodeProjectSet.c:175
#10 0x000056243885e048 in ExecProjectSet (pstate=0x562439604640) at
nodeProjectSet.c:105
#11 0x000056243881953a in ExecProcNodeFirst (node=0x562439604640) at
execProcnode.c:464
#12 0x000056243880c718 in ExecProcNode (node=0x562439604640) at
../../../src/include/executor/executor.h:262
#13 0x000056243880f54d in ExecutePlan (estate=0x562439604418,
planstate=0x562439604640, use_parallel_mode=false, operation=CMD_SELECT,
sendTuples=true, numberTuples=0, 
    direction=ForwardScanDirection, dest=0x56243960ad38, execute_once=true)
at execMain.c:1633
#14 0x000056243880ce00 in standard_ExecutorRun (queryDesc=0x56243960e768,
direction=ForwardScanDirection, count=0, execute_once=true) at
execMain.c:364
#15 0x000056243880cc09 in ExecutorRun (queryDesc=0x56243960e768,
direction=ForwardScanDirection, count=0, execute_once=true) at
execMain.c:308
#16 0x0000562438ac07cd in PortalRunSelect (portal=0x5624395843e8,
forward=true, count=0, dest=0x56243960ad38) at pquery.c:924
#17 0x0000562438ac03f5 in PortalRun (portal=0x5624395843e8,
count=9223372036854775807, isTopLevel=true, run_once=true,
dest=0x56243960ad38, altdest=0x56243960ad38, qc=0x7ffe83e284d0)
    at pquery.c:768
#18 0x0000562438ab91de in exec_simple_query (query_string=0x56243950ae88
"SELECT gist_page_items(get_raw_page('test_gist_btree', 0),
'test_gist_idx');") at postgres.c:1240
#19 0x0000562438abe21a in PostgresMain (dbname=0x562439542368 "egorchin",
username=0x562439542348 "egorchin") at postgres.c:4572
#20 0x00005624389e1f40 in BackendRun (port=0x562439539b80) at
postmaster.c:4461
#21 0x00005624389e17cc in BackendStartup (port=0x562439539b80) at
postmaster.c:4189
#22 0x00005624389ddb11 in ServerLoop () at postmaster.c:1779
#23 0x00005624389dd3bb in PostmasterMain (argc=3, argv=0x5624395053b0) at
postmaster.c:1463
#24 0x00005624388974e1 in main (argc=3, argv=0x5624395053b0) at main.c:200

Hi,

Attached fix for "master" branch.

-- 
With best regards,
Dmitry Koval

Postgres Professional: http://postgrespro.com

On Wed, Mar 01, 2023 at 12:31:47PM +0300, Dmitry Koval wrote:
> Attached fix for "master" branch.

SELECT gist_page_items(get_raw_page('test_gist_btree', 0), 'test_gist_idx');

So you have been mixing more than one index AM type to trigger that,
and the second argument fails already if we don't pass down a gist
index.

gist.sql has some coverage, but not for a combination like that.  Like
the recent things done in this area, well, I don't see why this one
could not be plugged as well..  I'll see into it.
--
Michael

On Wed, Mar 01, 2023 at 08:01:33PM +0900, Michael Paquier wrote:
> gist.sql has some coverage, but not for a combination like that.  Like
> the recent things done in this area, well, I don't see why this one
> could not be plugged as well..  I'll see into it.

Okay, done and backpatched.  I have added a similar test for BRIN,
while on it, as it relies on a raw page and an index when listing its
items.
--
Michael

> Okay, done and backpatched.  I have added a similar test for BRIN,
> while on it, as it relies on a raw page and an index when listing its
> items.

Thank you!

-- 
With best regards,
Dmitry Koval

Postgres Professional: http://postgrespro.com

On Thu, Mar 02, 2023 at 09:14:32AM +0300, Dmitry Koval wrote:
> Thank you!

No problem.  That was a nice catch.
--
Michael