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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FailedAssertion("pd_idx == pinfo->nparts", File: "execPartition.c", Line: 1689)
Date: 2020-08-06 04:02:28
Message-ID: 2598266.1596686548@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> writes:
> On Thu, Aug 6, 2020 at 2:22 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2020-08-06 04:11:46 Re: Which SET TYPE don't actually require a rewrite
Previous Message Andy Fan 2020-08-06 03:49:36 Re: FailedAssertion("pd_idx == pinfo->nparts", File: "execPartition.c", Line: 1689)