Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k2yb6-0006Bw-4b for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Aug 2020 15:11:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k2yb5-0000V5-2H for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Aug 2020 15:11:23 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k2yb4-0000Uy-Ns for pgsql-hackers@lists.postgresql.org; Tue, 04 Aug 2020 15:11:22 +0000 Received: from mail-io1-xd44.google.com ([2607:f8b0:4864:20::d44]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k2yb2-00071S-3y for pgsql-hackers@postgresql.org; Tue, 04 Aug 2020 15:11:21 +0000 Received: by mail-io1-xd44.google.com with SMTP id g19so30485100ioh.8 for ; Tue, 04 Aug 2020 08:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=kt5fK/oL5rK4pqjJUABF4/cZa6Dy6zllYQLprDGDn0o=; b=X195DAXCpD5vhm1s6oxRrZ5Bp1FJaM7Te+29Joc6Q7IajROyX0Xvnd3VMFgNbeT+PK DrF57zim4iJ169+Qo28epRAUVb2+6g8a1RLOWqh8vbaJIgsKCBU/JehPo+LjnTQZVuD7 TkWDrmm7GeDhnuyDZWfaowbWsANw5Jx+u+GN4ibGtwpQKBvqALA0GBaUoKVbg0i4c5Iu kVf99ZwUwm34dC1F4PKxRGZHLIz35UyxOFf6/+JHRjiQjoSy7W8Hnuvgt6krWB5NiF2R 9KhAixkO0urAN52iyQK9w1c4w5ADs7/9lVz8sPu/vxbBGsfyXG5lh8dzp8y2NcO8yPp2 GOoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=kt5fK/oL5rK4pqjJUABF4/cZa6Dy6zllYQLprDGDn0o=; b=uCoeswT/wEKiAXnX6dPVYbRuKF9QkzCfMbA4exOcr09iDF7PBafE6DYS5ofPCG1c7R QV4wPuZMWwrZrBAW2gldrR3usKKOlxVS8LW2ES/KiGerkVvoBpb493v+0FZ7DsdDhQHI rp6PswBhqUQj7GQKSFjunxfTyx8HhnwuhmUsd085i/mGa4swvl+mnxAqsEWPs/6N2IZM E2P9m4u5YZ+FszjreG4PcFMgV8S3rjDNb0FtaS3zwtl4jZZ+qDJqH5cKoihroZG9aJNc BR9TNE+k6pLSqZ3U244FhuTKgOpZ6R3a+XKIjyyRsXPqwLras5audsTD0ZpRjPvEtduM aLHg== X-Gm-Message-State: AOAM5313d9jLEMHBxAhp3QvJGVzv+USq8xRdDXZ6eRl4DwH3ME+oj+Va vkeCXCKxx1ksX88V3P+uPnc2Bg== X-Google-Smtp-Source: ABdhPJw47n/bRPHIcJZOIwqIccNDWA0Lh6Byd8Q4uL3Rnl9RlVi/Ro5I04pOdtVflHj38pM7//6Gmw== X-Received: by 2002:a05:6602:1685:: with SMTP id s5mr5492657iow.84.1596553879290; Tue, 04 Aug 2020 08:11:19 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id h18sm5822686iow.16.2020.08.04.08.11.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2020 08:11:18 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 2CACA8001AD; Tue, 4 Aug 2020 10:11:17 -0500 (CDT) Date: Tue, 4 Aug 2020 10:11:17 -0500 From: Justin Pryzby To: Amit Langote Cc: Robert Haas , pgsql-hackers@postgresql.org Subject: Re: FailedAssertion("pd_idx == pinfo->nparts", File: "execPartition.c", Line: 1689) Message-ID: <20200804151116.GP28072@telsasoft.com> References: <20200802181131.GA27754@telsasoft.com> <20200803161133.GA21372@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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=) at execPartition.c:1689 1689 execPartition.c: No such file or directory. $27 = {ps = {type = T_AppendState, plan = 0x7036b90, state = 0x11563f0, ExecProcNode = 0x6842c0 , 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