Re: A very quick observation of dangling pointers in Postgres pathlists
| От | Andrei Lepikhov |
|---|---|
| Тема | Re: A very quick observation of dangling pointers in Postgres pathlists |
| Дата | |
| Msg-id | 1b67f95c-27a5-42dd-8c95-efe452094dc3@gmail.com обсуждение |
| Ответ на | Re: A very quick observation of dangling pointers in Postgres pathlists (David Rowley <dgrowleyml@gmail.com>) |
| Ответы |
Re: A very quick observation of dangling pointers in Postgres pathlists
|
| Список | pgsql-hackers |
On 21/04/2026 10:35, David Rowley wrote: > On Tue, 21 Apr 2026 at 19:29, Andrei Lepikhov <lepihov@gmail.com> wrote: >> I've attached a patch that shows how to fix the issue. Some regression tests >> change because of a hidden rule where a projection and its subpath have >> different target lists. Right now, the patch always enforces a projection, even >> if the target lists are the same. This is still open for discussion on whether >> there's a better way to handle it. > > 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. It would be great to have a copy_path() function. At the moment, I create a limited version each time in an extension module, using reparameterize_path_by_child as a guide since it ensures the core can handle path copies. Do you mean we can introduce such a copy routine to fix current issue? Here is the problem: dangling pointers are detected only by external tools. I can't imagine an SQL reproducer to test this machinery. -- regards, Andrei Lepikhov, pgEdge
В списке pgsql-hackers по дате отправления: