> 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.
In other words, this is use-after-free, with add_path freeing the passed-in Path pointer, but one particular case in which this Path is still used afterwards.
> I tried to get a fix for this but no luck so far.
I proposed to add an add_path_extended() function that adds 'bool free_input_path' argument, and pass it false in that one place in create_ordered_paths.
Yeah, this can be a way.
However, I am thinking the other way around now. What if we first added the unmodified input path as it is to the ordered_rel first?
If we do so, then while adding the next path, add_path() may decide to remove the older one as the newer path is the best one. The remove_old logic in add_path() will free the path (unsorted one), and we end up with the same error.
And if we conditionally remove that path (remove_old logic one), then we need to pass false in every add_path() call in create_ordered_paths().