On 17.04.2026 11:56, Andrei Lepikhov wrote:
> Hi,
>
> It looks like a community decision has been developing that Postgres should
> separate optimisation features into 'conventional' and 'magic' classes [1]. This
> has raised my concern that hidden contracts about pathlists' state and ordering
> could lead to subtle bugs if an extension optimisation goes too far.
>
> I think this topic is of interest because of the growing number of features that
> impact path choice, such as ‘disable node’ or pg_plan_advice. Also, emerging
> techniques that involve two or more levels of plan trees, like ‘eager
> aggregation’, might catch another dangling pointer hidden in path lists for a
> while. Don’t forget complicated cases with FDW and Custom nodes too.
>
> For this purpose, a tiny debugging extension module, pg_pathcheck [2], has been
> invented. It uses create_upper_paths_hook and planner_shutdown_hook. The
> extension walks the entire Path tree, starting from the top PlannerInfo, then
> recurses into glob::subroots, traversing each RelOptInfo and each pathlist.
> Also, it traverses the path→subpath subtrees to ensure that potentially quite
> complex path trees are covered when implemented as a single RelOptInfo. For each
> pointer it visits, it checks if the NodeTag matches a known Path type. If not,
> the memory was freed (and, with CLOBBER_FREED_MEMORY, set to 0x7F) or reused for
> something else.
>
> This approach is not free of caveats. For example, most Path nodes and many Plan
> nodes fall within the 128-byte gap of the minimal allocated chunk. That means
> freeing one path allows the optimiser to immediately allocate another Path node
> at a potentially different query tree level. I had such a case at least once in
> production. It was actually hard to realise, reproduce, and fix.
Hi! I raised such a problem before in this thread and proposed a patch
to delete freed refused paths from pathlist.
You can find it here [0] of you are interested.
[0]
https://www.postgresql.org/message-id/flat/CAExHW5uhc5JVOUExjo24oYLLcJAyD04%2BBRb080sV08pO_%3D7w%3DA%40mail.gmail.com#2c0c5f2aca79753e1c8886d3f54e7d25
--
-----------
Best regards,
Alena Rybakina
