Error in list.c on line 391 (failed assertion)

[pylSER]

Original title: However, Does this project even work?

I have read your excellent paper in sigmod this year and I would really like to try this out.

However, Does this project even work?

I have complied the .so and preload it in to my postgresql(12.0 and 12.6) according to the setup tutorial. But it crashes every time I execute a query. The log is:

2021-08-02 19:48:58.014 CST [1505078] LOG:  redo is not required
2021-08-02 19:48:58.027 CST [1505034] LOG:  database system is ready to accept connections
**_TRAP: FailedAssertion("!(n >= 0)", File: "list.c", Line: 391)_**
2021-08-02 19:49:59.787 CST [1505034] LOG:  server process (PID 1505247) was terminated by signal 6: Abor
ted
2021-08-02 19:49:59.787 CST [1505034] DETAIL:  Failed process was running: EXPLAIN SELECT count(*) FROM t
itle;
2021-08-02 19:49:59.787 CST [1505034] LOG:  terminating any other active server processes
2021-08-02 19:49:59.787 CST [1505082] WARNING:  terminating connection because of crash of another server
 process
2021-08-02 19:49:59.787 CST [1505082] DETAIL:  The postmaster has commanded this server process to roll b
ack the current transaction and exit, because another server process exited abnormally and possibly corru
pted shared memory.
2021-08-02 19:49:59.787 CST [1505082] HINT:  In a moment you should be able to reconnect to the database
and repeat your command.
2021-08-02 19:49:59.788 CST [1505283] FATAL:  the database system is in recovery mode
2021-08-02 19:49:59.788 CST [1505034] LOG:  all server processes terminated; reinitializing
2021-08-02 19:49:59.803 CST [1505284] LOG:  database system was interrupted; last known up at 2021-08-02
19:48:58 CST
2021-08-02 19:49:59.889 CST [1505284] LOG:  database system was not properly shut down; automatic recover
y in progress
2021-08-02 19:49:59.894 CST [1505284] LOG:  redo starts at 2/6359B3D0
2021-08-02 19:49:59.894 CST [1505284] LOG:  invalid record length at 2/6359B408: wanted 24, got 0
2021-08-02 19:49:59.894 CST [1505284] LOG:  redo done at 2/6359B3D0
2021-08-02 19:49:59.911 CST [1505034] LOG:  database system is ready to accept connections

I doubt that maybe we are using different pg version.

Can you provide the exact postgres version that are tested?

[RyanMarcus]

However, Does this project even work?

Yes! It does. At least for me. :)

I do not know what is causing the error you are experiencing, which appears to be in the Postgres list implementation. The Bao extension doesn't directly interact with that code at all, so I'm not entirely sure how to help you.

You could try using the pre-built Docker image that already has the IMDB data and the Bao extension built:

docker run -p 127.0.0.1:5432:5432/tcp --add-host host.docker.internal:host-gateway --shm-size=8g ryanmarcus/imdb_bao:v1

Otherwise, could you run PG inside of GDB or Valgrind and see if you can get a stack trace for that error?

[pylSER]

Here is the stack:

#2  0x000056468bf12267 in ExceptionalCondition (conditionName=0x56468c0f8382 "!(n >= 0)",
    errorType=0x56468c0f80e7 "FailedAssertion", fileName=0x56468c0f80e0 "list.c", lineNumber=391) at assert.c:54
#3  0x000056468bc08ed5 in list_nth_cell (list=0x56468e174b88, n=-1) at list.c:391
#4  0x000056468bc08fa5 in list_nth (list=0x56468e174b88, n=-1) at list.c:413
#5  0x00007fbe9d04c9c8 in should_bao_optimize (parse=0x56468e1731c8) at bao_util.h:80
#6  0x00007fbe9d04f0c1 in bao_planner (parse=0x56468e1731c8, cursorOptions=256, boundParams=0x0) at main.c:174
#7  0x000056468bc83255 in planner (parse=0x56468e1731c8, cursorOptions=256, boundParams=0x0) at planner.c:273
#8  0x000056468bd93b99 in pg_plan_query (querytree=0x56468e1731c8, cursorOptions=256, boundParams=0x0) at postgres.c:878
#9  0x000056468bd93cca in pg_plan_queries (querytrees=0x56468e17d4c8, cursorOptions=256, boundParams=0x0) at postgres.c:968
#10 0x000056468bd93f9f in exec_simple_query (
    query_string=0x56468e0b35e8 "SELECT n.nspname as \"Schema\",\n  c.relname as \"Name\",\n  CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN 'm' THEN 'materialized view' WHEN 'i' THEN 'index' WHEN 'S' THEN 'sequence' WHEN '"...)
    at postgres.c:1143
#11 0x000056468bd98627 in PostgresMain (argc=1, argv=0x56468e0de118, dbname=0x56468e0ddf78 "postgres",
    username=0x56468e0ddf50 ) at postgres.c:4261
#12 0x000056468bce905f in BackendRun (port=0x56468e0d5070) at postmaster.c:4484
#13 0x000056468bce87a9 in BackendStartup (port=0x56468e0d5070) at postmaster.c:4167
#14 0x000056468bce4a4a in ServerLoop () at postmaster.c:1725
#15 0x000056468bce4291 in PostmasterMain (argc=3, argv=0x56468e0ae0d0) at postmaster.c:1398
#16 0x000056468bbffa57 in main (argc=3, argv=0x56468e0ae0d0) at main.c:228
(gdb) f 5
#5  0x00007fbe9d04c9c8 in should_bao_optimize (parse=0x56468e1731c8) at bao_util.h:80
80	    relid = rt_fetch(i, parse->rtable)->relid;

It turns out that the index parameter in function rt_fetch starts with 1.

/*
 *		rt_fetch
 *
 * NB: this will crash and burn if handed an out-of-range RT index
 */
#define rt_fetch(rangetable_index, rangetable) \
	((RangeTblEntry *) list_nth(rangetable, (rangetable_index)-1))

I fixed the code and it worked. The pull request is above.