From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
---|---|
To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: More issues with expressions always false (no patch) |
Date: | 2019-12-20 00:54:53 |
Message-ID: | f53ed33d-4869-8a32-4b35-cae674ddefca@proxel.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/20/19 1:01 AM, Ranier Vilela wrote:> First case:
> src \ backend \ executor \ nodeSubplan.c (line 507)
>
> if (node-> hashtable)
>
> node-> hastable is assigned with NULL at line 498, so the test will
> always fail.
>
> Second case:
> Here the case is similar, but worse.
>
> src \ backend \ executor \ nodeSubplan.c (line 535)
> if (node-> hashnulls)
> ResetTupleHashTable (node-> hashtable);
These two look like likely bugs. It looks like the code will always
create new hash tables despite commit
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=356687bd825e5ca7230d43c1bffe7a59ad2e77bd
intending to reset them if they already exist.
Additionally it looks like the code would reset the wrong hash table in
the second place if the bug was fixed.
I have attached a patch.
> 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.
Andreas
Attachment | Content-Type | Size |
---|---|---|
fix-subplan-hash-reset.patch | text/x-patch | 1.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-12-20 01:06:56 | Re: [HACKERS] kqueue |
Previous Message | Ranier Vilela | 2019-12-20 00:42:06 | Re: [PATCH] Fix expressions always false |