Re: unrecognized node type while displaying a Path due to dangling pointer
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeevan Chalke <jeevan.chalke@enterprisedb.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-07-17T03:18:30Z
Lists: pgsql-hackers
Attachments
- flat_copy_node.patch (text/plain) patch
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've attached a draft patch which adds copyObjectFlat() and supports all Node types asides from the ones mentioned in @extra_tags in gen_node_support.pl. This did require including all the node header files in copyfuncs.c, which that file seems to have avoided until now. 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. I was also unsure what we should do when shallow copying a List. The problem there is if we just do a shallow copy, a repalloc() on the elements array would end up pfreeing memory that might be used by a shallow copied clone. Perhaps List is not unique in that regard? Maybe the solution there is to add a special case and list_copy() Lists like what is done in copyObjectImpl(). I'm hoping the attached patch will at least assist in moving the discussion along. David