Put a critical section around update of hash index metapage. Per

discussion with Qingqing Zhou.

diff --git a/src/backend/access/hash/hashpage.c b/src/backend/access/hash/hashpage.c
index 6b974683f81c22d65e672245fb2d66531f9c4f7f..75f5ab03ce67111d8400da4102a031620a87e62b 100644 (file)
--- 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