forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit5c27bce
committed
Clear dangling pointer to avoid bogus EXPLAIN printout in a corner case.
ExecReScanHashJoin will destroy the join's hash table if it expectsthat the inner relation will produce different rows on rescan.Up to now it's not bothered to clear the additional pointer to thathash table that exists in the child HashState node. However, it'spossible for the query to terminate without building a fresh hashtable (this happens if the outer relation is found to be emptyduring the final rescan). So we can end with a dangling pointerto a deleted hash table. That was harmless originally, but since9.0 EXPLAIN ANALYZE has used that pointer to print hash tablestatistics. In debug builds this reproducibly results in garbagestatistics. In non-debug builds there's frequently no ill effects,but in principle one could get wrong EXPLAIN ANALYZE output, orperhaps even a crash if free() has released the hashtable memoryback to the OS.To fix, just make sure we clear the additional pointer when destroyingthe hash table. In problematic cases, EXPLAIN ANALYZE will then printno hashtable statistics (reverting to its pre-9.0 behavior). This isn'tideal, but since the problem manifests only in unusual corner cases,it's hard to justify taking any risks to do better in the backbranches. A follow-on patch will improve matters in HEAD.Konstantin Knizhnik and Tom Lane, per diagnosis by Thomas Munroof a trouble report from Alvaro Herrera.Discussion:https://postgr.es/m/20200323165059.GA24950@alvherre.pgsql1 parent12fb189 commit5c27bce
1 file changed
+6
-0
lines changedLines changed: 6 additions & 0 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
1336 | 1336 |
| |
1337 | 1337 |
| |
1338 | 1338 |
| |
| 1339 | + | |
| 1340 | + | |
| 1341 | + | |
| 1342 | + | |
| 1343 | + | |
| 1344 | + | |
1339 | 1345 |
| |
1340 | 1346 |
| |
1341 | 1347 |
| |
|
0 commit comments
Comments
(0)