• Tom Lane's avatar
    Clear dangling pointer to avoid bogus EXPLAIN printout in a corner case. · 5c27bce7
    Tom Lane authored
    ExecReScanHashJoin will destroy the join's hash table if it expects
    that the inner relation will produce different rows on rescan.
    Up to now it's not bothered to clear the additional pointer to that
    hash table that exists in the child HashState node.  However, it's
    possible for the query to terminate without building a fresh hash
    table (this happens if the outer relation is found to be empty
    during the final rescan).  So we can end with a dangling pointer
    to a deleted hash table.  That was harmless originally, but since
    9.0 EXPLAIN ANALYZE has used that pointer to print hash table
    statistics.  In debug builds this reproducibly results in garbage
    statistics.  In non-debug builds there's frequently no ill effects,
    but in principle one could get wrong EXPLAIN ANALYZE output, or
    perhaps even a crash if free() has released the hashtable memory
    back to the OS.
    
    To fix, just make sure we clear the additional pointer when destroying
    the hash table.  In problematic cases, EXPLAIN ANALYZE will then print
    no hashtable statistics (reverting to its pre-9.0 behavior).  This isn't
    ideal, but since the problem manifests only in unusual corner cases,
    it's hard to justify taking any risks to do better in the back
    branches.  A follow-on patch will improve matters in HEAD.
    
    Konstantin Knizhnik and Tom Lane, per diagnosis by Thomas Munro
    of a trouble report from Alvaro Herrera.
    
    Discussion: https://postgr.es/m/20200323165059.GA24950@alvherre.pgsql
    5c27bce7
nodeHashjoin.c 46.6 KB