PHJ file leak. - Mailing list pgsql-hackers

Hello. While looking a patch, I found that PHJ sometimes complains for
file leaks if accompanied by LIMIT.

Repro is very simple:

create table t as (select a, a as b from generate_series(0, 999999) a);
analyze t;
select t.a from t join t t2 on (t.a = t2.a) limit 1;

Once in several (or dozen of) times execution of the last query
complains as follows.

WARNING:  temporary file leak: File 15 still referenced
WARNING:  temporary file leak: File 17 still referenced

This is using PHJ and the leaked file was a shared tuplestore for
outer tuples, which was opend by sts_parallel_scan_next() called from
ExecParallelHashJoinOuterGetTuple(). It seems to me that
ExecHashTableDestroy is forgeting to release shared tuplestore
accessors. Please find the attached.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/executor/nodeHash.c b/src/backend/executor/nodeHash.c
index 224cbb32ba..8399683569 100644
--- a/src/backend/executor/nodeHash.c
+++ b/src/backend/executor/nodeHash.c
@@ -871,6 +871,9 @@ ExecHashTableDestroy(HashJoinTable hashtable)
         }
     }
 
+    /* Also, free up accessors to shared tuplestores if any */
+    ExecParallelHashCloseBatchAccessors(hashtable);
+
     /* Release working memory (batchCxt is a child, so it goes away too) */
     MemoryContextDelete(hashtable->hashCxt);
 
@@ -2991,6 +2994,7 @@ ExecParallelHashCloseBatchAccessors(HashJoinTable hashtable)
         sts_end_parallel_scan(hashtable->batches[i].outer_tuples);
     }
     pfree(hashtable->batches);
+    hashtable->nbatch = 0;
     hashtable->batches = NULL;
 }