From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andreas Karlsson <andreas(at)proxel(dot)se> |
Cc: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, peter(dot)eisentraut(at)2ndquadrant(dot)com |
Subject: | Re: More issues with expressions always false (no patch) |
Date: | 2019-12-20 21:34:38 |
Message-ID: | 10896.1576877678@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andreas Karlsson <andreas(at)proxel(dot)se> writes:
> On 12/20/19 1:54 AM, Andreas Karlsson wrote:
>> On 12/20/19 1:01 AM, Ranier Vilela wrote:> First case:
>>> Third case:
>>> \ src \ backend \ utils \ cache \ relcache.c (line 5190)
>>> if (relation-> rd_pubactions)
>>>
>>> It will never be executed, because if relation-> rd_pubactions is
>>> true, the function returns on line 5154.
>> I have not looked into this one in detail, but the free at line 5192
>> looks like potentially dead code.
> I have looked at it now and it seems like this code has been dead since
> the function was originally implemented in 665d1fad99e.
I would not put a whole lot of faith in that. This argument supposes
that nothing else can touch the relcache entry while we are doing
GetRelationPublications and the pg_publication syscache accesses inside
the foreach loop. Now in practice, yeah, it's somewhat unlikely that
anything down inside there would take an interest in our relation's
publication actions, especially if our relation isn't a system catalog.
But there are closely related situations in other relcache functions
that compute cached values like this where we *do* have to worry about
reentrant/recursive use of the function. I think the "useless" free
is cheap insurance against a permanent memory leak, as well as more
like the coding in nearby functions like RelationGetIndexAttrBitmap.
I wouldn't change it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2019-12-20 21:38:32 | Re: Session WAL activity |
Previous Message | Tom Lane | 2019-12-20 21:19:40 | Re: Disallow cancellation of waiting for synchronous replication |