Feedback-ID: ia2694551:Fastmail
Date: Mon, 13 May 2024 18:55:36 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tender Wang <tndrwang@gmail.com>
Cc: 1026592243@qq.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts",
 fileName="execPartition.c", lineNumber=1943
Message-ID: <202405131655.zqmzo7idv7ho@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAHewXNkaKgVmT+OkVA9UHrEYm+b8J6o_8+-84Qey6V5tM-+z9A@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202405131655.zqmzo7idv7ho%40alvherre.pgsql>
Precedence: bulk

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/