From 914ae8d3cbbe480f8002a38deef4a5319970d2f4 Mon Sep 17 00:00:00 2001 From: Robert Haas 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!