Re: unrecognized node type while displaying a Path due to dangling pointer

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: unrecognized node type while displaying a Path due to dangling pointer
Дата
Msg-id 3926249.1689564692@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: unrecognized node type while displaying a Path due to dangling pointer  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: unrecognized node type while displaying a Path due to dangling pointer
Список pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> On Wed, 12 Jul 2023 at 14:50, David Rowley <dgrowleyml@gmail.com> wrote:
>> On Wed, 12 Jul 2023 at 14:23, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I did think about that, but "shallow copy a Path" seems nontrivial
>>> because the Path structs are all different sizes.  Maybe it is worth
>>> building some infrastructure to support that?

>> It seems a reasonable thing to have to do.  It seems the minimum thing
>> we could do to ensure each Path is only mentioned in at most 1
>> RelOptInfo.

> ...
> I also didn't do anything about ExtensibleNode types. I assume just
> copying the ExtensibleNode isn't good enough. To flat copy the actual
> node I think would require adding a new function to
> ExtensibleNodeMethods.

Yeah, the problem I've got with this approach is that flat-copying
FDW and Custom paths would require extending the respective APIs.
While that's a perfectly reasonable ask if we only need to do this
in HEAD, it would be a nonstarter for released branches.  Is it
okay to only fix this issue in HEAD?

> I was also unsure what we should do when shallow copying a List.

The proposal is to shallow-copy a Path node.  List is not a kind
of Path, so how does List get into it?  (Lists below Paths would
not get copied, by definition.)

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: unrecognized node type while displaying a Path due to dangling pointer
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: Inefficiency in parallel pg_restore with many tables