Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit4e32f8c

Browse files
committed
Fix hash_search to avoid corruption of the hash table on out-of-memory.
An out-of-memory error during expand_table() on a palloc-based hash tablewould leave a partially-initialized entry in the table. This would not beharmful for transient hash tables, since they'd get thrown away anyway attransaction abort. But for long-lived hash tables, such as the relcachehash, this would effectively corrupt the table, leading to crash or othermisbehavior later.To fix, rearrange the order of operations so that table enlargement isattempted before we insert a new entry, rather than after adding itto the hash table.Problem discovered by Hitoshi Harada, though this is a bit differentfrom his proposed patch.
1 parent0d68950 commit4e32f8c

File tree

1 file changed

+30
-16
lines changed

1 file changed

+30
-16
lines changed

‎src/backend/utils/hash/dynahash.c

Lines changed: 30 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,11 @@
2121
* lookup key's hash value as a partition number --- this will work because
2222
* of the way calc_bucket() maps hash values to bucket numbers.
2323
*
24+
* For hash tables in shared memory, the memory allocator function should
25+
* match malloc's semantics of returning NULL on failure. For hash tables
26+
* in local memory, we typically use palloc() which will throw error on
27+
* failure. The code in this file has to cope with both cases.
28+
*
2429
* Portions Copyright (c) 1996-2012, PostgreSQL Global Development Group
2530
* Portions Copyright (c) 1994, Regents of the University of California
2631
*
@@ -820,6 +825,27 @@ hash_search_with_hash_value(HTAB *hashp,
820825
hctl->accesses++;
821826
#endif
822827

828+
/*
829+
* If inserting, check if it is time to split a bucket.
830+
*
831+
* NOTE: failure to expand table is not a fatal error, it just means we
832+
* have to run at higher fill factor than we wanted. However, if we're
833+
* using the palloc allocator then it will throw error anyway on
834+
* out-of-memory, so we must do this before modifying the table.
835+
*/
836+
if (action==HASH_ENTER||action==HASH_ENTER_NULL)
837+
{
838+
/*
839+
* Can't split if running in partitioned mode, nor if frozen, nor if
840+
* table is the subject of any active hash_seq_search scans. Strange
841+
* order of these tests is to try to check cheaper conditions first.
842+
*/
843+
if (!IS_PARTITIONED(hctl)&& !hashp->frozen&&
844+
hctl->nentries / (long) (hctl->max_bucket+1) >=hctl->ffactor&&
845+
!has_seq_scans(hashp))
846+
(void)expand_table(hashp);
847+
}
848+
823849
/*
824850
* Do the initial lookup
825851
*/
@@ -940,24 +966,12 @@ hash_search_with_hash_value(HTAB *hashp,
940966
currBucket->hashvalue=hashvalue;
941967
hashp->keycopy(ELEMENTKEY(currBucket),keyPtr,keysize);
942968

943-
/* caller is expected to fill the data field on return */
944-
945969
/*
946-
*Check if itistime tosplit a bucket. Can't split if running
947-
*in partitioned mode, nor if table is the subject of any active
948-
*hash_seq_search scans. Strange order of these tests is to try
949-
*to check cheaper conditions first.
970+
*Callerisexpected tofill the data field on return. DO NOT
971+
*insert any code that could possibly throw error here, as doing
972+
*so would leave the table entry incomplete and hence corrupt the
973+
*caller's data structure.
950974
*/
951-
if (!IS_PARTITIONED(hctl)&&
952-
hctl->nentries / (long) (hctl->max_bucket+1) >=hctl->ffactor&&
953-
!has_seq_scans(hashp))
954-
{
955-
/*
956-
* NOTE: failure to expand table is not a fatal error, it just
957-
* means we have to run at higher fill factor than we wanted.
958-
*/
959-
expand_table(hashp);
960-
}
961975

962976
return (void*)ELEMENTKEY(currBucket);
963977
}

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp