Re: FailedAssertion("pd_idx == pinfo->nparts", File: "execPartition.c", Line: 1689) - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: FailedAssertion("pd_idx == pinfo->nparts", File: "execPartition.c", Line: 1689)
Date
Msg-id 20200804151116.GP28072@telsasoft.com
Whole thread Raw
In response to Re: FailedAssertion("pd_idx == pinfo->nparts", File: "execPartition.c", Line: 1689)  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
On Tue, Aug 04, 2020 at 08:12:10PM +0900, Amit Langote wrote:
> It may be this commit that went into PG 12 that is causing the problem:

Thanks for digging into this.

> to account for partitions that were pruned by the planner for which we
> decided to put 0 into relid_map, but it only considered the case where
> the number of partitions doesn't change since the plan was created.
> The crash reported here is in the other case where the concurrently
> added partitions cause the execution-time PartitionDesc to have more
> partitions than the one that PartitionedRelPruneInfo is based on.

Is there anything else needed to check that my crash matches your analysis ?

(gdb) up
#4  0x000000000068444a in ExecInitAppend (node=node@entry=0x7036b90, estate=estate@entry=0x11563f0,
eflags=eflags@entry=16)at nodeAppend.c:132
 
132     nodeAppend.c: No such file or directory.
(gdb) p *node->appendplans   
$17 = {type = T_List, length = 413, max_length = 509, elements = 0x7037400, initial_elements = 0x7037400}

(gdb) down
#3  0x0000000000672806 in ExecCreatePartitionPruneState (planstate=planstate@entry=0x908f6d8,
partitionpruneinfo=<optimizedout>) at execPartition.c:1689
 
1689    execPartition.c: No such file or directory.

$27 = {ps = {type = T_AppendState, plan = 0x7036b90, state = 0x11563f0, ExecProcNode = 0x6842c0 <ExecAppend>,
ExecProcNodeReal= 0x0, instrument = 0x0, worker_instrument = 0x0, worker_jit_instrument = 0x0, 
 
    qual = 0x0, lefttree = 0x0, righttree = 0x0, initPlan = 0x0, subPlan = 0x0, chgParam = 0x0, ps_ResultTupleDesc =
0x0,ps_ResultTupleSlot = 0x0, ps_ExprContext = 0x908f7f0, ps_ProjInfo = 0x0, scandesc = 0x0, 
 
    scanops = 0x0, outerops = 0x0, innerops = 0x0, resultops = 0x0, scanopsfixed = false, outeropsfixed = false,
inneropsfixed= false, resultopsfixed = false, scanopsset = false, outeropsset = false, 
 
    inneropsset = false, resultopsset = false}, appendplans = 0x0, as_nplans = 0, as_whichplan = -1,
as_first_partial_plan= 0, as_pstate = 0x0, pstate_len = 0, as_prune_state = 0x0, as_valid_subplans = 0x0, 
 
  choose_next_subplan = 0x0}

-- 
Justin



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: LSM tree for Postgres
Next
From: Tomas Vondra
Date:
Subject: Re: LSM tree for Postgres