Date: Tue, 18 Oct 2022 21:50:17 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: dafoer_x@163.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17650: For the sixth time, the clipping function in the 120
 partition table planning stage fails
Message-ID: <20221018135017.cefttdymnmooh4af@jrouhaud>
References: <17650-4523221bc4eb0c33@postgresql.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <17650-4523221bc4eb0c33@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/20221018135017.cefttdymnmooh4af%40jrouhaud>
Precedence: bulk

Hi,

On Tue, Oct 18, 2022 at 01:11:13PM +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference:      17650
> Logged by:          dafoer
> Email address:      dafoer_x@163.com
> PostgreSQL version: 14.0

Unrelated but you should definitely update to the latest minor version,
currently 14.5

> Operating system:   centos7.6
> Description:
>
> The clipping function of partition table cannot be carried out normally in
> the planning stage. The extension protocol cannot be clipped in the sixth
> execution. When concurrency is high, lock contention is serious

I'm not sure I fully understand.  Are you saying that partition pruning (1)
doesn't happen after 6 execution of a prepared statement?  If yes, it's not a
bug but a known behavior of generic plans.  You can dynamically set
plan_cache_mode to force_custom_plan for the cases where generic plans are
known to behave poorly.

[1] https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING