[sqlsmith] Parallel worker executor crash on master

From: Andreas Seltenreich <seltenreich(at)gmx(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: [sqlsmith] Parallel worker executor crash on master
Date: 2017-12-15 19:27:14
Message-ID: 87mv2ju6zx.fsf@ansel.ydns.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

sqlsmith just crashed a parallel worker while testing master at
699bf7d05c. I can reproduce it with the following recipe on a fresh
regression database. Backtrace and query plan below as well.

regards,
Andreas

--8<---------------cut here---------------start------------->8---
set min_parallel_table_scan_size = '8kB';
set parallel_setup_cost = 0;
set parallel_tuple_cost = 0;

select *
from
public.prt1_m_p3 as ref_3
inner join pg_catalog.pg_class as sample_1 tablesample bernoulli (2.1)
on (ref_3.c = sample_1.relpages )
inner join public.rtest_view4 as ref_4
on (ref_4.b @@ (select keyword from public.test_tsquery limit 1 offset 2)
),
lateral (select
ref_3.a as c0
from
public.lseg_tbl as ref_5
where (select f1 from public.timetz_tbl limit 1 offset 5)
> (select pg_catalog.min(timetzcol) from public.brintest)
limit 18) as subq_2
where true
limit 102;
--8<---------------cut here---------------end--------------->8---

QUERY PLAN
-----------------------------------------------------------------------------------------------------------
Limit (cost=107.69..1421.69 rows=102 width=315)
InitPlan 1 (returns $1)
-> Limit (cost=0.35..0.52 rows=1 width=32)
-> Gather (cost=0.00..1.04 rows=6 width=32)
Workers Planned: 1
-> Parallel Seq Scan on test_tsquery (cost=0.00..1.04 rows=4 width=32)
-> Nested Loop (cost=107.17..5775.39 rows=440 width=315)
Join Filter: (ref_3.c = sample_1.relpages)
-> Nested Loop (cost=107.17..5416.40 rows=250 width=16)
-> Gather (cost=0.00..1.29 rows=50 width=12)
Workers Planned: 1
-> Parallel Seq Scan on prt1_m_p3 ref_3 (cost=0.00..1.29 rows=29 width=12)
-> Limit (cost=107.17..108.20 rows=5 width=4)
InitPlan 2 (returns $4)
-> Limit (cost=0.45..0.54 rows=1 width=12)
-> Gather (cost=0.00..1.07 rows=12 width=12)
Workers Planned: 1
-> Parallel Seq Scan on timetz_tbl (cost=0.00..1.07 rows=7 width=12)
InitPlan 3 (returns $5)
-> Aggregate (cost=106.62..106.64 rows=1 width=12)
-> Seq Scan on brintest (cost=0.00..106.30 rows=130 width=12)
-> Gather (cost=0.00..1.03 rows=5 width=4)
Workers Planned: 1
Params Evaluated: $4, $5
-> Result (cost=0.00..1.03 rows=3 width=0)
One-Time Filter: ($4 > $5)
-> Parallel Seq Scan on lseg_tbl ref_5 (cost=0.00..1.03 rows=3 width=0)
-> Materialize (cost=0.00..194.10 rows=44 width=299)
-> Nested Loop (cost=0.00..193.88 rows=44 width=299)
-> Gather (cost=0.00..140.00 rows=1 width=40)
Workers Planned: 2
Params Evaluated: $1
-> Parallel Seq Scan on rtest_view4 ref_4 (cost=0.00..140.00 rows=1 width=40)
Filter: (b @@ $1)
-> Sample Scan on pg_class sample_1 (cost=0.00..53.44 rows=44 width=259)
Sampling: bernoulli ('2.1'::real)

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055c9dba2d7f8 in timetz_gt (fcinfo=0x55c9dd7295a0) at date.c:2183
2183 TimeTzADT *time2 = PG_GETARG_TIMETZADT_P(1);
#1 0x000055c9db8ae8b2 in ExecInterpExpr (state=0x55c9dd729f00, econtext=0x55c9dd7299b8, isnull=<optimized out>) at execExprInterp.c:692
#2 0x000055c9db8d6753 in ExecEvalExprSwitchContext (isNull=0x7ffd2f99e55f "", econtext=0x55c9dd7299b8, state=<optimized out>) at ../../../src/include/executor/executor.h:300
#3 ExecQual (econtext=0x55c9dd7299b8, state=<optimized out>) at ../../../src/include/executor/executor.h:369
#4 ExecResult (pstate=0x55c9dd729c38) at nodeResult.c:84
#5 0x000055c9db8b21ea in ExecProcNode (node=0x55c9dd729c38) at ../../../src/include/executor/executor.h:242
#6 ExecutePlan (execute_once=<optimized out>, dest=0x55c9dd6fff78, direction=<optimized out>, numberTuples=18, sendTuples=<optimized out>, operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=0x55c9dd729c38, estate=0x55c9dd729118) at execMain.c:1718
#7 standard_ExecutorRun (queryDesc=0x55c9dd742b48, direction=<optimized out>, count=18, execute_once=<optimized out>) at execMain.c:361
#8 0x000055c9db8b6e99 in ParallelQueryMain (seg=0x55c9dd6a8ea8, toc=0x7f9109496000) at execParallel.c:1294
#9 0x000055c9db7911d9 in ParallelWorkerMain (main_arg=<optimized out>) at parallel.c:1150
#10 0x000055c9db975a63 in StartBackgroundWorker () at bgworker.c:841
#11 0x000055c9db982015 in do_start_bgworker (rw=0x55c9dd6a0380) at postmaster.c:5741
#12 maybe_start_bgworkers () at postmaster.c:5954
#13 0x000055c9db982ae8 in sigusr1_handler (postgres_signal_arg=<optimized out>) at postmaster.c:5134
#14 <signal handler called>
#15 0x00007f91088503d3 in select () from /lib/x86_64-linux-gnu/libc.so.6
#16 0x000055c9db7024ed in ServerLoop () at postmaster.c:1721
#17 0x000055c9db984194 in PostmasterMain (argc=3, argv=0x55c9dd67a5a0) at postmaster.c:1365
#18 0x000055c9db70448d in main (argc=3, argv=0x55c9dd67a5a0) at main.c:228

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthew Kelly 2017-12-15 19:47:32 Bug: Ambiguous Column Reference Allowed When Joining to pg_roles.oid
Previous Message Andres Freund 2017-12-15 19:19:30 Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple