From: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, ranier(dot)vf(at)gmail(dot)com |
Subject: | Re: list_free in addRangeTableEntryForJoin |
Date: | 2024-06-10 13:45:39 |
Message-ID: | 9d3dbecc-ee7b-419c-aad3-3ef1b098540e@tantorlabs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
0003-list-free.patch | text/x-patch | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2024-06-10 13:53:50 | Re: confirmed flush lsn seems to be move backward in certain error cases |
Previous Message | Robert Haas | 2024-06-10 13:14:59 | Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids) |