unrecognized node type while displaying a Path due to dangling pointer - Mailing list pgsql-hackers

Hello,

While debugging one issue, we have added the below line in postgresGetForeignPlan() to see the foreignrel details.

@@ -1238,6 +1238,8 @@ postgresGetForeignPlan(PlannerInfo *root,
    bool        has_limit = false;
    ListCell   *lc;
 
+   elog(INFO, "foreignrel: %s", nodeToString(foreignrel));
+

And with this change, we ran the postgres_fdw regression (executing sql/postgres_fdw.sql) suite. We observed the below warnings that seem strange.

+WARNING:  could not dump unrecognized node type: 0
+WARNING:  could not dump unrecognized node type: 26072088
+WARNING:  could not dump unrecognized node type: 26438448
+WARNING:  could not dump unrecognized node type: 368

Of course, with multiple runs, we see some random node types listed above. Thanks to my colleague Suraj Kharage for this and for working parallel with me.

Does anybody have any idea about these?

After debugging one random query from the above-failed case, what we have observed is (we might be wrong, but worth noting here):

1. This warning ended up while displaying RelOptInfo->pathlist.
2. In create_ordered_paths(), input_rel has two paths, and it loops over both paths to get the best-sorted path.
3. First path was unsorted, and thus we add a sort node on top of it, and adds that to the ordered_rel.
4. However, 2nd path was already sorted and passed as is to the add_path().
5. add_path() decides to reject this new path on some metrics. However, in the end, it pfree() this passed in path. It seems wrong as its references do present elsewhere. For example, in the first path's parent rels path list.
6. So, while displaying the parent's path, we end up with these warnings.

I tried to get a fix for this but no luck so far.
One approach was to copy the path before passing it to the add_path(). However, there is no easy way to copy a path due to its circular references.

To see whether this warning goes or not, I have commented code in add_path() that does pfree() on the new_path. And with that, I don't see any warnings. But removing that code doesn't seem to be the correct fix.

Suggestions?

Thanks
--