Segmentation fault occurred in parallel query

[git-itake]

Hi.

Segmentation faults occur in queries where parallel queries are used.
However, no issue will occur under the following conditions.
· disabled pg_hint_plan
(SET pg_hint_plan.enable_hint TO off;)
· disabled Parallel query
(max_parallel_workers_per_gather = 0 / max_parallel_workers = 0)
· Specify parallel execution method
(/ * + SeqScan (a) Parallel (a 1 soft) * /)

Segmentation fault will be reproduced by the following test.
Is this a bug?

=# SELECT version();
PostgreSQL 10.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit

=# \dx
Name | Version | Schema | Description
--------------+---------+------------+------------------------------
pg_hint_plan | 1.3.1 | hint_plan |

(test)
$ pgbench -i -s 10 testdb
$ LANG=C psql testdb
=# LOAD 'pg_hint_plan';
=# /*+ SeqScan(a) */ EXPLAIN (ANALYZE, BUFFERS) SELECT a.aid FROM pgbench_accounts AS a INNER JOIN pgbench_accounts AS b ON a.aid = b.aid ORDER BY a.aid;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

(log)
LOG: server process (PID 1750) was terminated by signal 11: Segmentation fault
DETAIL: Failed process was running: /*+ SeqScan(a) */ EXPLAIN (ANALYZE, BUFFERS) SELECT a.aid FROM pgbench_accounts AS a INNER JOIN pgbench_accounts AS b ON a.aid = b.aid ORDER BY a.aid;
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.

(gdb) bt
#0 copyObjectImpl (from=0x3eb0c6f7a0b5ed8d) at copyfuncs.c:4679
#1 0x000000000067e95b in create_scan_plan (root=0x1277a38, best_path=0x1278c78, flags=) at createplan.c:567
#2 0x000000000067cadd in create_plan_recurse (root=0x1277a38, best_path=0x1278c78, flags=0) at createplan.c:378
#3 0x000000000067cb38 in create_mergejoin_plan (root=0x1277a38, best_path=0x12805b8, flags=1) at createplan.c:3787
#4 create_join_plan (root=0x1277a38, best_path=0x12805b8, flags=1) at createplan.c:953
#5 create_plan_recurse (root=0x1277a38, best_path=0x12805b8, flags=1) at createplan.c:383
#6 0x0000000000680685 in create_gather_merge_plan (root=0x1277a38, best_path=0x12804b8) at createplan.c:1504
#7 0x000000000067c816 in create_plan_recurse (root=0x1277a38, best_path=0x12804b8, flags=1) at createplan.c:488
#8 0x000000000067da19 in create_plan (root=0x1277a38, best_path=) at createplan.c:315
#9 0x000000000068a2cb in standard_planner (parse=0x1275a28, cursorOptions=256, boundParams=) at planner.c:341
#10 0x00007f916dc05508 in pg_hint_plan_planner (parse=0x1275a28, cursorOptions=256, boundParams=0x0) at pg_hint_plan.c:3035
#11 0x00000000007245fa in pg_plan_query (querytree=, cursorOptions=, boundParams=) at postgres.c:796
#12 0x00000000005990b7 in ExplainOneQuery (query=0x1275a28, cursorOptions=, into=0x0, es=0x11c96d8,
queryString=0x1225528 "/*+ SeqScan(a) / EXPLAIN (ANALYZE, BUFFERS) SELECT a.aid FROM pgbench_accounts AS a INNER JOIN pgbench_accounts AS b ON a.aid = b.aid ORDER BY a.aid;",
params=0x0, queryEnv=0x0) at explain.c:367
#13 0x000000000059933d in ExplainQuery (pstate=0x11c9538, stmt=0x1226a78,
queryString=0x1225528 "/+ SeqScan(a) / EXPLAIN (ANALYZE, BUFFERS) SELECT a.aid FROM pgbench_accounts AS a INNER JOIN pgbench_accounts AS b ON a.aid = b.aid ORDER BY a.aid;",
params=0x0, queryEnv=0x0, dest=0x11c9648) at explain.c:256
#14 0x000000000072b12d in standard_ProcessUtility (pstmt=0x1227060,
queryString=0x1225528 "/+ SeqScan(a) / EXPLAIN (ANALYZE, BUFFERS) SELECT a.aid FROM pgbench_accounts AS a INNER JOIN pgbench_accounts AS b ON a.aid = b.aid ORDER BY a.aid;",
context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x11c9648, completionTag=0x7fff48ab3ab0 "") at utility.c:680
#15 0x000000000072705b in PortalRunUtility (portal=0x125ccc8, pstmt=0x1227060, isTopLevel=, setHoldSnapshot=, dest=0x11c9648,
completionTag=) at pquery.c:1178
#16 0x000000000072826a in FillPortalStore (portal=0x125ccc8, isTopLevel=1 '\001') at pquery.c:1038
#17 0x0000000000728758 in PortalRun (portal=0x125ccc8, count=9223372036854775807, isTopLevel=1 '\001', run_once=1 '\001', dest=0x1227410, altdest=0x1227410,
completionTag=0x7fff48ab3cd0 "") at pquery.c:768
#18 0x0000000000724c81 in exec_simple_query (
query_string=0x1225528 "/+ SeqScan(a) */ EXPLAIN (ANALYZE, BUFFERS) SELECT a.aid FROM pgbench_accounts AS a INNER JOIN pgbench_accounts AS b ON a.aid = b.aid ORDER BY a.aid;")
at postgres.c:1099
#19 0x0000000000725c39 in PostgresMain (argc=, argv=, dbname=0x11a3cd8 "testdb", username=) at postgres.c:4088
#20 0x00000000006b9aca in BackendRun (argc=, argv=) at postmaster.c:4405
#21 BackendStartup (argc=, argv=) at postmaster.c:4077
#22 ServerLoop (argc=, argv=) at postmaster.c:1755
#23 PostmasterMain (argc=, argv=) at postmaster.c:1363
#24 0x000000000063a130 in main (argc=1, argv=0x11a1ba0) at main.c:228

[za-arthur]

Does the pull request #14 fix your segfault?

[git-itake]

I did a pull request # 14 fix and recompiled, but the problem was not solved.

[suseque]

I am having the same issue. Is this fixed?

[horiguti]

I saw this is fixed by the commit 26d0dec . Index pathes wrongly left alone leads to dereferencing to already removed Index infos. The bug is PG10 only.