Re: pgsql: Enable parallel SELECT for "INSERT INTO ... SELECT ...".

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Kapila <akapila(at)postgresql(dot)org>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Greg Nancarrow <gregn4422(at)gmail(dot)com>
Subject: Re: pgsql: Enable parallel SELECT for "INSERT INTO ... SELECT ...".
Date: 2021-03-10 04:16:35
Message-ID: CAA4eK1JE5vVEaUg1mgMkb31+tTeJo9k2+m+i5_9CYy=Nq=h+LA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Wed, Mar 10, 2021 at 9:07 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Kapila <akapila(at)postgresql(dot)org> writes:
> > Enable parallel SELECT for "INSERT INTO ... SELECT ...".
>
> skink (valgrind) is unhappy:
>
> creating configuration files ... ok
> running bootstrap script ... ok
> performing post-bootstrap initialization ... ==4085668== VALGRINDERROR-BEGIN
> ==4085668== Conditional jump or move depends on uninitialised value(s)
> ==4085668== at 0x4AEB77: max_parallel_hazard_walker (clauses.c:700)
> ==4085668== by 0x445287: expression_tree_walker (nodeFuncs.c:2188)
> ==4085668== by 0x4AEBB8: max_parallel_hazard_walker (clauses.c:860)
> ==4085668== by 0x4B045E: is_parallel_safe (clauses.c:637)
> ==4085668== by 0x4985D0: grouping_planner (planner.c:2070)
> ==4085668== by 0x49AE4F: subquery_planner (planner.c:1024)
> ==4085668== by 0x49B4F5: standard_planner (planner.c:404)
> ==4085668== by 0x49BAD2: planner (planner.c:273)
> ==4085668== by 0x5818BE: pg_plan_query (postgres.c:809)
> ==4085668== by 0x581977: pg_plan_queries (postgres.c:900)
> ==4085668== by 0x581E70: exec_simple_query (postgres.c:1092)
> ==4085668== by 0x583F7A: PostgresMain (postgres.c:4327)
> ==4085668== Uninitialised value was created by a stack allocation
> ==4085668== at 0x4B0363: is_parallel_safe (clauses.c:599)
> ==4085668==
> ==4085668== VALGRINDERROR-END
>
> There are a few other commits that skink hasn't seen before, but given
> the apparent connection to parallel planning, none of the others look
> like plausible candidates to explain this.
>

Right, the patch forgot to initialize a new variable in
max_parallel_hazard_context via is_parallel_safe. I think we need to
initialize all the new variables as NULL because is_parallel_safe is
used to check parallel-safety of expressions. These new variables are
only required for checking parallel-safety of target relation which is
already done at the time of initial checks in standard_planner.

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Amit Kapila 2021-03-10 04:43:14 pgsql: Fix valgrind issue in commit 05c8482f7f.
Previous Message Tom Lane 2021-03-10 03:37:35 Re: pgsql: Enable parallel SELECT for "INSERT INTO ... SELECT ...".

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-03-10 04:51:53 Re: New Table Access Methods for Multi and Single Inserts
Previous Message Masahiko Sawada 2021-03-10 03:46:31 Re: a verbose option for autovacuum