Re: A very quick observation of dangling pointers in Postgres pathlists

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: A very quick observation of dangling pointers in Postgres pathlists
Date: 2026-04-29 12:43:02
Message-ID: 6f6fa20f-1019-4bf6-ab76-c30c046b0efe@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27/04/2026 10:19, Andrei Lepikhov wrote:
> On 21/04/2026 10:35, David Rowley wrote:
>> IMO, we should write a function like copy_path() or reparent_path(),
>> which creates a copy of the given Path, or the latter also would copy
>> then set the ->parent to the given RelOptInfo. Any time we use a path
>> directly from the pathlist of another RelOptInfo, we should reparent
>> or copy it. We could add an Assert in add_path() to check the new path
>> has the correct parent to help us find the places where we forget to
>> do this.
>
> I've attached the patch so we can keep the discussion going.

While playing with random path choices [1], I found additional cases where a
path is assigned to two different RelOptInfos. See the attachment for a modified
patch.

[1] https://github.com/danolivo/pg-chaos-test

--
regards, Andrei Lepikhov,
pgEdge

Attachment Content-Type Size
v1-0001-Fix-dangling-Path-pointers-when-sharing-paths-acr.patch text/plain 9.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-04-29 12:58:47 Re: [Bug][patch]: After dropping the last label from a property graph element, invoking pg_get_propgraphdef() triggers an assertion failure
Previous Message Daniel Gustafsson 2026-04-29 12:41:32 Re: Changing the state of data checksums in a running cluster