From 82358ca936f93dbbc49455ce8c3fd3d8e7a8cf3e Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Thu, 9 Jun 2005 18:23:50 +0000 Subject: [PATCH] Put a critical section around update of hash index metapage. Per discussion with Qingqing Zhou. --- src/backend/access/hash/hashpage.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/backend/access/hash/hashpage.c b/src/backend/access/hash/hashpage.c index 6b974683f8..75f5ab03ce 100644 --- a/src/backend/access/hash/hashpage.c +++ b/src/backend/access/hash/hashpage.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/access/hash/hashpage.c,v 1.49 2005/05/11 01:26:01 neilc Exp $ + * $PostgreSQL: pgsql/src/backend/access/hash/hashpage.c,v 1.50 2005/06/09 18:23:50 tgl Exp $ * * NOTES * Postgres hash pages look like ordinary relation pages. The opaque @@ -421,7 +421,15 @@ _hash_expandtable(Relation rel, Buffer metabuf) /* * Okay to proceed with split. Update the metapage bucket mapping * info. + * + * Since we are scribbling on the metapage data right in the shared + * buffer, any failure in this next little bit leaves us with a big + * problem: the metapage is effectively corrupt but could get written + * back to disk. We don't really expect any failure, but just to be + * sure, establish a critical section. */ + START_CRIT_SECTION(); + metap->hashm_maxbucket = new_bucket; if (new_bucket > metap->hashm_highmask) @@ -456,6 +464,9 @@ _hash_expandtable(Relation rel, Buffer metabuf) if (!_hash_try_getlock(rel, start_nblkno, HASH_EXCLUSIVE)) elog(PANIC, "could not get lock on supposedly new bucket"); + /* Done mucking with metapage */ + END_CRIT_SECTION(); + /* * Copy bucket mapping info now; this saves re-accessing the meta page * inside _hash_splitbucket's inner loop. Note that once we drop the