Re: More issues with expressions always false (no patch)
Andreas Karlsson <andreas@proxel.se>
From: Andreas Karlsson <andreas@proxel.se>
To: Ranier Vilela <ranier.vf@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2019-12-20T00:54:53Z
Lists: pgsql-hackers
Attachments
- fix-subplan-hash-reset.patch (text/x-patch) patch
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
Commits
-
Correctly re-use hash tables in buildSubPlanHash().
- 9eb6b652a46d 11.8 landed
- 96d783ae55b9 12.3 landed
- 58c47ccfff20 13.0 landed
-
Reset, not recreate, execGrouping.c style hashtables.
- 356687bd825e 12.0 cited