Re: list_free in addRangeTableEntryForJoin - Mailing list pgsql-hackers

From Ilia Evdokimov
Subject Re: list_free in addRangeTableEntryForJoin
Date
Msg-id 9d3dbecc-ee7b-419c-aad3-3ef1b098540e@tantorlabs.com
Whole thread Raw
In response to Re: list_free in addRangeTableEntryForJoin  (Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>)
Responses Re: list_free in addRangeTableEntryForJoin
List pgsql-hackers
 >Now you need to analyze whether the memory in question is not managed 
by a Context
I've already analyzed. Let's explain details:


1. analyze.c
1718: List* targetnames;
1815: targetnames = NIL;
1848: targetnames = lappend(targetnames, makeString(colName));
1871: addRangeTableEntryForJoin(...);
=> list_free(targetnames);

2. parse_clause.c
1163: List* res_colnames;
1289: res_colnames = NIL;
1324: foreach(col, res_colnames);
1396: res_colnames = lappend(res_colnames, lfirst(ucol));
1520, 1525: extractRemainingColumns(...);
        |
     290: *res_colnames = lappend(*res_colnames, lfirst(lc));
1543: addRangeTableEntryForJoin(...);
=> list_free(res_colnames);


As you can see, there are no other pointers working with this block of 
memory, and all operations above are either read-only or append nodes to 
the lists. If I am mistaken, please correct me.
Furthermore, I will call `list_free` immediately after 
`addRangeTableEntryForJoin()`. The new patch is attached.

Thanks for reviewing. I'm looking forward to new suggestions.

Regards,

Ilia Evdokimov,

Tantor Labs LCC

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids)
Next
From: vignesh C
Date:
Subject: Re: confirmed flush lsn seems to be move backward in certain error cases