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[email protected]

diff --git a/src/backend/utils/hash/dynahash.c b/src/backend/utils/hash/dynahash.c
index 12b1658c9ad973eb8460b5e358d9b4f34edbcf15..1adc5841f735973cbd5e9929528c93eee0ab428a 100644 (file)
--- 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!