From 914ae8d3cbbe480f8002a38deef4a5319970d2f4 Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Tue, 25 Apr 2017 10:57:13 -0400
Subject: [PATCH] Adjust outdated comment.

Commit 5dfc198146b49ce7ecc8a1fc9d5e171fb75f6ba5 removed the only
existing caller of hash_freeze, but left behind a comment indicating
that hash_freeze was still used.  Adjust.

Kyotaro Horiguchi

Discussion: http://postgr.es/m/20170424.165541.230634914.horiguchi.kyotaro@lab.ntt.co.jp
---
 src/backend/utils/hash/dynahash.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/backend/utils/hash/dynahash.c b/src/backend/utils/hash/dynahash.c
index 12b1658c9ad..1adc5841f73 100644
--- a/src/backend/utils/hash/dynahash.c
+++ b/src/backend/utils/hash/dynahash.c
@@ -1330,9 +1330,7 @@ hash_get_num_entries(HTAB *hashp)
  *
  * NOTE: it is possible to use hash_seq_init/hash_seq_search without any
  * worry about hash_seq_term cleanup, if the hashtable is first locked against
- * further insertions by calling hash_freeze.  This is used by nodeAgg.c,
- * wherein it is inconvenient to track whether a scan is still open, and
- * there's no possibility of further insertions after readout has begun.
+ * further insertions by calling hash_freeze.
  *
  * NOTE: to use this with a partitioned hashtable, caller had better hold
  * at least shared lock on all partitions of the table throughout the scan!
-- 
GitLab