Re: BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails
| От | Julien Rouhaud |
|---|---|
| Тема | Re: BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails |
| Дата | |
| Msg-id | 20221018135017.cefttdymnmooh4af@jrouhaud обсуждение исходный текст |
| Ответ на | BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails (PG Bug reporting form <noreply@postgresql.org>) |
| Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: