[Bug] create index using rum coredump

[huey97]

Database Version: PostgreSQL 14.12
RUM extension version: rum 1.3
VECTOR extension: vector 0.6.2
Operating System: RHEL 8

The structure of the tables in the database is as follows:
create extension rum;
create extension vector;
CREATE TABLE test_table (
a bigint,
b character varying(32),
c character varying(32),
d character varying(32),
e smallint,
f character varying(64),
g timestamp,
h text[],
i integer,
j text,
k public.vector(1536),
l text,
m tsvector,
n smallint,
p timestamp,
q timestamp
);

For security reasons, the data in the table cannot be provided directly. I found that when I inserted 40,000 or so rows into the table, the create index behaved differently as the amount of data changed.

CREATE INDEX idx ON public.test_table USING rum (h, m rum_tsvector_addon_ops) WITH (ATTACH='h', TO='m') WHERE id < 20000; will failed with "cannot store a toast pointer inside a range" in rumdatapage.c:115。

CREATE INDEX idx ON public.test_table USING rum (h, m rum_tsvector_addon_ops) WITH (ATTACH='h', TO='m') WHERE id < 40000 will coredump at "elog(ERROR, "cannot store a toast pointer inside a range");" in rumdatapage.c:115.
The reason for coredump via ERROR here is that createPostingTree is in START_CRIT_SECTION() of ruminsert.c:67; The coredump is generated in subsequent errors.

The coredump stack is as follows：
SQL: CREATE INDEX idx ON public.test_table USING rum (h, m rum_tsvector_addon_ops) WITH (ATTACH='h', TO='m');

#0 0x00007efd1ad2b9d5 in raise () from /lib64/libc.so.6
#1 0x00007efd1ad14894 in abort () from /lib64/libc.so.6
#2 0x0000000000e352c0 in errfinish (filename=0x7efc90b5da77 "rumdatapage.c", lineno=115,
funcname=0x7efc90b5df50 <func.3> "rumDatumWrite") at elog.c:785
#3 0x00007efc90b3aed9 in rumDatumWrite (ptr=0x7efca521402b "", datum=139623223228960, typbyval=false,
typalign=105 'i', typlen=-1, typstorage=120 'x') at src/rumdatapage.c:115
#4 0x00007efc90b3b465 in rumPlaceToDataPageLeaf (ptr=0x7efca521402b "", attnum=2, item=0x3f2a560,
prev=0x7ffdc605beda, rumstate=0x7ffdc605c580) at src/rumdatapage.c:241
#5 0x00007efc90b4a5d8 in createPostingTree (rumstate=0x7ffdc605c580, attnum=2, index=0x7efc90b898d0,
items=0x3f2a560, nitems=368) at src/ruminsert.c:84
#6 0x00007efc90b4afdc in buildFreshLeafTuple (rumstate=0x7ffdc605c580, attnum=2, key=139623223243288,
category=0 '\000', items=0x3f2a560, nitem=1791, buildStats=0x7ffdc6061740) at src/ruminsert.c:375
#7 0x00007efc90b4b487 in rumEntryInsert (rumstate=0x7ffdc605c580, attnum=2, key=139623223243288,
category=0 '\000', items=0x3f2a560, nitem=1791, buildStats=0x7ffdc6061740) at src/ruminsert.c:475
#8 0x00007efc90b4b9fb in rumBuildCallback (index=0x7efc90b898d0, tid=0x33879a4, values=0x33897f8,
isnull=0x3390ba8, tupleIsAlive=true, state=0x7ffdc605c580) at src/ruminsert.c:600
#9 0x000000000054ba31 in heapam_index_build_range_scan (heapRelation=0x7efc90b79f38,
indexRelation=0x7efc90b898d0, indexInfo=0x329cc10, allow_sync=false, anyvisible=false,
progress=true, start_blockno=0, numblocks=4294967295, callback=0x7efc90b4b7a7 ,
callback_state=0x7ffdc605c580, scan=0x3387940) at heapam_handler.c:1704
#10 0x00007efc90b4a297 in table_index_build_scan (table_rel=0x7efc90b79f38, index_rel=0x7efc90b898d0,
index_info=0x329cc10, allow_sync=false, progress=true, callback=0x7efc90b4b7a7 ,
callback_state=0x7ffdc605c580, scan=0x0) at ../../src/include/access/tableam.h:1808
#11 0x00007efc90b4bd16 in rumbuild (heap=0x7efc90b79f38, index=0x7efc90b898d0, indexInfo=0x329cc10)
at src/ruminsert.c:671
#12 0x00000000006917b0 in index_build (heapRelation=0x7efc90b79f38, indexRelation=0x7efc90b898d0,
indexInfo=0x329cc10, isreindex=false, parallel=true, build_type=INDEX_BUILD_CREATE) at index.c:3255
#13 0x000000000068dcd3 in index_create (heapRelation=0x7efc90b79f38,
indexRelationName=0x3242a50 "idx", indexRelationId=386702,
parentIndexRelid=0, parentConstraintId=0, relFileNode=0, indexInfo=0x329cc10,
indexColNames=0x33885e0, accessMethodObjectId=18070, tableSpaceId=0, collationObjectId=0x33887c0,
classObjectId=0x33887e0, coloptions=0x3388800, reloptions=54036056, flags=0, constr_flags=0,
allow_system_table_mods=false, is_internal=false, constraintId=0x7ffdc6061a9c) at index.c:1329
#14 0x000000000082722f in DefineIndex (relationId=18788, stmt=0x3243010, indexRelationId=0,
parentIndexId=0, parentConstraintId=0, is_alter_table=false, check_rights=true,
check_not_in_use=true, skip_build=false, quiet=false) at indexcmds.c:1398

[huey97]

CREATE INDEX idx ON public.test_table USING rum (h, m rum_tsvector_addon_ops) WITH (ATTACH='h', TO='m') WHERE a < 20000; will failed with "cannot store a toast pointer inside a range" in rumdatapage.c:115。

CREATE INDEX idx ON public.test_table USING rum (h, m rum_tsvector_addon_ops) WITH (ATTACH='h', TO='m') WHERE a < 40000 will coredump at "elog(ERROR, "cannot store a toast pointer inside a range");" in rumdatapage.c:115.
The reason for coredump via ERROR here is that createPostingTree is in START_CRIT_SECTION() of ruminsert.c:67; The coredump is generated in subsequent errors.

[sokolcati]

This error occurs, because we must never put a toast pointer inside a range object. Caller should have detoasted it.

The dependence on the number of rows may be due to the fact that at 40,000+ lines the toaster starts to be used.