On Wed, Aug 5, 2020 at 9:52 AM Amit Langote <amitlangote09@gmail.com> wrote:
> On Wed, Aug 5, 2020 at 9:32 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> > On Wed, Aug 05, 2020 at 09:26:20AM +0900, Amit Langote wrote:
> > > On Wed, Aug 5, 2020 at 12:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> > > >
> > > > 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 ?
> > >
> > > If you can spot a 0 in the output of the following, then yes.
> > >
> > > (gdb) p *pinfo->relid_map@pinfo->nparts
> >
> > I guess you knew that an earlier message has just that. Thanks.
> > https://www.postgresql.org/message-id/20200803161133.GA21372@telsasoft.com
>
> Yeah, you showed:
>
> (gdb) p *pinfo->relid_map@414
>
> And there is indeed a 0 in there, but I wasn't sure if it was actually
> in the array or a stray zero due to forcing gdb to show beyond the
> array bound. Does pinfo->nparts match 414?
(sorry, I forgot to hit reply all in last two emails.)
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com