On Tue, Jul 11, 2023 at 1:19 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> On 2023-Jul-11, Jeevan Chalke wrote: > > > 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(). Am I missing something? Thanks > > -- > Álvaro Herrera 48°01'N 7°57'E — > https://www.EnterpriseDB.com/ > -- Jeevan Chalke *Senior Staff SDE, Database Architect, and ManagerProduct Development* edbpostgres.com
