Message-ID: <6eae7e84-03a7-4741-a8c9-59ace5d3b476@yandex.ru>
Date: Tue, 21 Apr 2026 11:46:33 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: A very quick observation of dangling pointers in Postgres
 pathlists
To: Andrei Lepikhov <lepihov@gmail.com>
References: <adab9758-f346-4263-93af-3e37b7b315b7@gmail.com>
Content-Language: en-US
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
From: Alena Rybakina <lena.ribackina@yandex.ru>
In-Reply-To: <adab9758-f346-4263-93af-3e37b7b315b7@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/6eae7e84-03a7-4741-a8c9-59ace5d3b476%40yandex.ru>
Precedence: bulk

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