More parallel-query fun

As of HEAD you can exercise quite a lot of parallel query behavior
by running the regression tests with these settings applied:

force_parallel_mode = regress
max_parallel_workers_per_gather = 2 -- this is default at the moment
min_parallel_relation_size = 0
parallel_setup_cost = 0
parallel_tuple_cost = 0

This results in multiple interesting failures, including a core dump
here:

Program terminated with signal 11, Segmentation fault.
#0 shm_mq_set_handle (mqh=0x0, handle=0x1ac3090) at shm_mq.c:312
312 Assert(mqh->mqh_handle == NULL);
(gdb) bt
#0 shm_mq_set_handle (mqh=0x0, handle=0x1ac3090) at shm_mq.c:312
#1 0x00000000004e0fd9 in LaunchParallelWorkers (pcxt=0x1ac2dd8)
at parallel.c:479
#2 0x00000000005f40fd in ExecGather (node=0x1b05508) at nodeGather.c:168
#3 0x00000000005e3011 in ExecProcNode (node=0x1b05508) at execProcnode.c:515
#4 0x00000000005fe795 in ExecNestLoop (node=0x1afe7f0) at nodeNestloop.c:174
#5 0x00000000005e2f87 in ExecProcNode (node=0x1afe7f0) at execProcnode.c:476
#6 0x000000000060135b in ExecSort (node=0x1afe520) at nodeSort.c:103
#7 0x00000000005e2fc7 in ExecProcNode (node=0x1afe520) at execProcnode.c:495
#8 0x00000000005e15c8 in ExecutePlan (queryDesc=0x1a44f98,
direction=NoMovementScanDirection, count=0) at execMain.c:1567
#9 standard_ExecutorRun (queryDesc=0x1a44f98,
direction=NoMovementScanDirection, count=0) at execMain.c:338
#10 0x00000000005e16b6 in ExecutorRun (queryDesc=<value optimized out>,
direction=<value optimized out>, count=<value optimized out>)
at execMain.c:286

(gdb) p debug_query_string
$1 = 0x1a965e8 "SELECT n.nspname as \"Schema\",\n p.proname AS \"Name\",\n pg_catalog.format_type(p.prorettype, NULL) AS \"Result data type\",\n CASE WHEN p.pronargs = 0\n THEN CAST('*' AS pg_catalog.text)\n ELSE pg_ca"...

The statement that triggers this varies from run to run, but the proximate
cause, namely error_mqh being null at parallel.c:479, seems consistent.
It looks to me like parallel.c's handling of insufficiently-many-workers
is a few bricks shy of a load.

I saw another previously-unreported problem before getting to the crash:

*** /home/postgres/pgsql/src/test/regress/expected/enum.out	Mon Oct 20 10:50:24 2014
--- /home/postgres/pgsql/src/test/regress/results/enum.out	Thu Jun 16 14:00:58 2016
***************
*** 284,306 ****
  -- Aggregates
  --
  SELECT min(col) FROM enumtest;
!  min 
! -----
!  red
! (1 row)
! 
  SELECT max(col) FROM enumtest;
!   max   
! --------
!  purple
! (1 row)
! 
  SELECT max(col) FROM enumtest WHERE col < 'green';
!   max   
! --------
!  yellow
! (1 row)
! 
  --
  -- Index tests, force use of index
  --
--- 284,294 ----
  -- Aggregates
  --
  SELECT min(col) FROM enumtest;
! ERROR:  type matched to anyenum is not an enum type: anyenum
  SELECT max(col) FROM enumtest;
! ERROR:  type matched to anyenum is not an enum type: anyenum
  SELECT max(col) FROM enumtest WHERE col < 'green';
! ERROR:  type matched to anyenum is not an enum type: anyenum
  --
  -- Index tests, force use of index
  --

Haven't tried to trace that one down yet.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers