From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tender Wang <tndrwang@gmail.com>
Cc: 1026592243@qq.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943
Date: Mon, 13 May 2024 18:55:36 +0200
Message-ID: <202405131655.zqmzo7idv7ho@alvherre.pgsql> (raw)
In-Reply-To: <CAHewXNkaKgVmT+OkVA9UHrEYm+b8J6o_8+-84Qey6V5tM-+z9A@mail.gmail.com>
On 2024-Apr-18, Tender Wang wrote:
> Now we switch to gdb2, breakpoint at RelationCacheInvalidateEntry(). We
> continue gdb2, and we will
> stop at RelationCacheInvalidateEntry(). And we will see that p relation
> cache item will be cleared.
> The backtrace will be attached at the end of the this email.
Here is where I think the problem occurs -- I mean, surely
PlanCacheRelCallback marking the plan as ->is_valid=false should cause
the prepared query to be replanned, and at that point the replan would
see that the partition is no more. So by the time we get to this:
> Entering ExecInitAppend(), because part_prune_info is not null, so we will
> enter CreatePartitionPruneState().
> We enter find_inheritance_children_extended() again to get partdesc, but in
> gdb1 we have done DetachPartitionFinalize()
> and the detach has commited. So we only get one tuple and parts is 1.
we have made a new plan, one whose planner partition descriptor has only
one partition, so it'd match what ExecInitAppend sees.
Evidently there's something I'm missing in how this plancache
invalidation works.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: alvherre@alvh.no-ip.org, tndrwang@gmail.com, 1026592243@qq.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943
In-Reply-To: <202405131655.zqmzo7idv7ho@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox