On Wed, Aug 5, 2020 at 9:52 AM Amit Langote <amitlangot...@gmail.com> wrote: > On Wed, Aug 5, 2020 at 9:32 AM Justin Pryzby <pry...@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 <pry...@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.ga21...@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
