Re: [sqlsmith] Failed assertions on parallel worker shutdown

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andreas Seltenreich <seltenreich(at)gmx(dot)de>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [sqlsmith] Failed assertions on parallel worker shutdown
Date: 2016-05-24 12:33:33
Message-ID: CAA4eK1KYN+TCNax36L4fodjJkmvw3yzjNeUr1smzUsxv4=2fEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 23, 2016 at 4:48 PM, Andreas Seltenreich <seltenreich(at)gmx(dot)de>
wrote:
>
> Amit Kapila writes:
>
> > Earlier problems were due to the reason that some unsafe/restricted
> > expressions were pushed below Gather node as part of target list
whereas in
> > the plan6, it seems some unsafe node is pushed below Gather node. It
will
> > be helpful if you can share the offending query?
>
> plan6 corresponds to this query:
>
> select
> pg_catalog.anyarray_out(
> cast((select most_common_vals from pg_catalog.pg_stats limit 1 offset
41)
> as anyarray)) as c0
> from
> public.quad_point_tbl as ref_0 where ref_0.p ~= ref_0.p;
>

Are you sure that the core dumps you are seeing are due to plan6? I have
tried to generate a parallel plan for above query and it seems to me that
after applying the patches (avoid_restricted_clause_below_gather_v1.patch
and prohibit_parallel_clause_below_rel_v1.patch), the plan it generates
doesn't have subplan below gather node [1]. Without patch
avoid_restricted_clause_below_gather_v1.patch, it will allow to push
subplan below gather node, so I think either there is some other plan
(query) due to which you are seeing core dumps or the above two patches
haven't been applied before testing. Is it possible that core dump is due
to plan2 or some other similar plan (I am not sure at this stage about the
cause of the problem you are seeing, but if due to some reason PARAM_EXEC
params are pushed below gather, then such a plan might not work)? If you
think plan other than plan6 can cause such a problem, then can you share
the query for plan2?

[1]
QUERY PLAN

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
------------------------------------
Gather (cost=543.59..5041.17 rows=1761 width=32)
Output: anyarray_out($0)
Workers Planned: 1
InitPlan 1 (returns $0)
-> Limit (cost=491.56..543.59 rows=1 width=32)
Output: pg_stats.most_common_vals
-> Subquery Scan on pg_stats (cost=127.30..491.56 rows=7
width=32)
Output: pg_stats.most_common_vals
-> Hash Join (cost=127.30..491.49 rows=7 width=401)
Output: NULL::name, NULL::name, NULL::name,
NULL::boolean, NULL::real, NULL::integer, NULL::real, CASE WHEN (s.stakind1
= 1) THEN s.stavalues1 WHEN (s.stakind2 = 1) THEN s.stavalues2 WHEN
(s.stakind3 = 1) THEN s.stavalues3 WHEN (s.stakind4 = 1) THEN s.stavalues4
WHEN (s.stakind5 = 1) THEN s.stavalues5 ELSE NULL::anyarray END,
NULL::real[], NULL::anyarray, NULL::real, NULL::anyarray, NULL::real[],
NULL::real[]
Hash Cond: ((a.attrelid = c.oid) AND (a.attnum =
s.staattnum))
Join Filter: has_column_privilege(c.oid, a.attnum,
'select'::text)
-> Seq Scan on pg_catalog.pg_attribute a
(cost=0.00..318.11 rows=6097 width=6)
Output: a.attrelid, a.attname, a.atttypid,
a.attstattarget, a.attlen, a.attnum, a.attndims, a.attcacheoff,
a.atttypmod, a.attbyval, a.attstorage, a.attalign, a.attnotnull,
a.atthasdef, a.attisdropped, a.attislocal, a.attinhcount, a.attcollation,
a.attacl, a.attoptions, a.attfdwoptions
Filter: (NOT a.attisdropped)
-> Hash (cost=117.59..117.59 rows=647 width=180)
Output: s.stakind1, s.stavalues1, s.stakind2,
s.stavalues2, s.stakind3, s.stavalues3, s.stakind4, s.stavalues4,
s.stakind5, s.stava
lues5, s.starelid, s.staattnum, c.oid
-> Hash Join (cost=57.21..117.59 rows=647
width=180)
Output: s.stakind1, s.stavalues1,
s.stakind2, s.stavalues2, s.stakind3, s.stavalues3, s.stakind4,
s.stavalues4, s.stakind5, s
.stavalues5, s.starelid, s.staattnum, c.oid
Hash Cond: (s.starelid = c.oid)
-> Seq Scan on pg_catalog.pg_statistic
s (cost=0.00..51.48 rows=648 width=176)
Output: s.starelid, s.staattnum,
s.stainherit, s.stanullfrac, s.stawidth, s.stadistinct, s.stakind1,
s.stakind2, s.stakind3, s.stakind4, s.stakind5, s.staop1, s.staop2,
s.staop3, s.staop4, s.staop5,s.stanumbers1, s.stanumbers2, s.stanumbers3,
s.stanumbers4, s.stanumbers5, s.sta
values1, s.stavalues2, s.stavalues3, s.stavalues4, s.stavalues5
-> Hash (cost=45.61..45.61 rows=928
width=8)
Output: c.oid, c.relnamespace
-> Seq Scan on
pg_catalog.pg_class c (cost=0.00..45.61 rows=928 width=8)
Output: c.oid, c.relnamespace
Filter: ((NOT
c.relrowsecurity) OR (NOT row_security_active(c.oid)))
-> Parallel Seq Scan on public.quad_point_tbl ref_0
(cost=0.00..4493.18 rows=1036 width=0)
Filter: (ref_0.p ~= ref_0.p)
(29 rows)

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Seltenreich 2016-05-24 13:06:25 Re: [sqlsmith] Failed assertions on parallel worker shutdown
Previous Message Teodor Sigaev 2016-05-24 12:29:28 Re: [PATCH] add missing "USING bloom" into bloom extension documentation