Re: list_free in addRangeTableEntryForJoin

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

In response to

Responses

Browse pgsql-hackers by date

  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)