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 1k3X6x-0001Cp-6h for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Aug 2020 04:02:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k3X6v-0003z2-7z for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Aug 2020 04:02:33 +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 1k3X6v-0003yv-0r for pgsql-hackers@lists.postgresql.org; Thu, 06 Aug 2020 04:02:33 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k3X6s-0000c1-R6 for pgsql-hackers@postgresql.org; Thu, 06 Aug 2020 04:02:32 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 07642Smp2598267; Thu, 6 Aug 2020 00:02:28 -0400 From: Tom Lane To: Andy Fan cc: Robert Haas , Amit Langote , Justin Pryzby , "pgsql-hackers@postgresql.org" Subject: Re: FailedAssertion("pd_idx == pinfo->nparts", File: "execPartition.c", Line: 1689) In-reply-to: References: <20200802181131.GA27754@telsasoft.com> <20200803161133.GA21372@telsasoft.com> <2528807.1596648630@sss.pgh.pa.us> <2550497.1596651719@sss.pgh.pa.us> Comments: In-reply-to Andy Fan message dated "Thu, 06 Aug 2020 11:49:36 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2598265.1596686548.1@sss.pgh.pa.us> Date: Thu, 06 Aug 2020 00:02:28 -0400 Message-ID: <2598266.1596686548@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andy Fan writes: > On Thu, Aug 6, 2020 at 2:22 AM Tom Lane wrote: >> In the longer term, it's annoying that we have no test methodology >> for this other than "manually set a breakpoint here". > One of the methods I see is we can just add some GUC variable for some > action injection. basically it adds some code based on the GUC like this; See my straw-man proposal downthread. I'm not very excited about putting things like this into the standard build, because it's really hard to be sure that there are no security-hazard-ish downsides of putting in ways to get at testing behaviors from standard SQL. And then there's the question of whether you're adding noticeable overhead to production builds. So a loadable module that can use some existing hook to provide the needed behavior seems like a better plan to me, whenever we can do it that way. In general, though, it seems like we've seldom regretted investments in test tooling. regards, tom lane