Re: [sqlsmith] Failed assertions on parallel worker shutdown
| От | Amit Kapila |
|---|---|
| Тема | Re: [sqlsmith] Failed assertions on parallel worker shutdown |
| Дата | |
| Msg-id | CAA4eK1KYN+TCNax36L4fodjJkmvw3yzjNeUr1smzUsxv4=2fEg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [sqlsmith] Failed assertions on parallel worker shutdown (Andreas Seltenreich <seltenreich@gmx.de>) |
| Ответы |
Re: [sqlsmith] Failed assertions on parallel worker shutdown
(Andreas Seltenreich <seltenreich@gmx.de>)
|
| Список | pgsql-hackers |
On Mon, May 23, 2016 at 4:48 PM, Andreas Seltenreich <seltenreich@gmx.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;
>
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
>
> 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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Teodor SigaevДата:
Сообщение: Re: [PATCH] add missing "USING bloom" into bloom extension documentation
Следующее
От: Andreas SeltenreichДата:
Сообщение: Re: [sqlsmith] Failed assertions on parallel worker shutdown