postgrespro / rum

RUM access method - inverted index with additional information in posting lists
Other
715 stars 52 forks source link

[Bug] create index using rum coredump #126

Open huey97 opened 2 months ago

huey97 commented 2 months ago

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 <rumBuildCallback>,
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 <rumBuildCallback>,
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 commented 2 months ago

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.