On Tue, Jul 11, 2023 at 2:58 PM Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote:
> > > 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(). > Attached patch. > > 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 > -- Jeevan Chalke *Senior Staff SDE, Database Architect, and ManagerProduct Development* edbpostgres.com
fix_add_path.patch
Description: Binary data
