|
8 | 8 | * |
9 | 9 | * |
10 | 10 | * IDENTIFICATION |
11 | | - * $PostgreSQL: pgsql/src/backend/access/hash/hashpage.c,v 1.49 2005/05/11 01:26:01 neilc Exp $ |
| 11 | + * $PostgreSQL: pgsql/src/backend/access/hash/hashpage.c,v 1.50 2005/06/09 18:23:50 tgl Exp $ |
12 | 12 | * |
13 | 13 | * NOTES |
14 | 14 | * Postgres hash pages look like ordinary relation pages. The opaque |
@@ -421,7 +421,15 @@ _hash_expandtable(Relation rel, Buffer metabuf) |
421 | 421 | /* |
422 | 422 | * Okay to proceed with split.Update the metapage bucket mapping |
423 | 423 | * info. |
| 424 | + * |
| 425 | + * Since we are scribbling on the metapage data right in the shared |
| 426 | + * buffer, any failure in this next little bit leaves us with a big |
| 427 | + * problem: the metapage is effectively corrupt but could get written |
| 428 | + * back to disk. We don't really expect any failure, but just to be |
| 429 | + * sure, establish a critical section. |
424 | 430 | */ |
| 431 | +START_CRIT_SECTION(); |
| 432 | + |
425 | 433 | metap->hashm_maxbucket=new_bucket; |
426 | 434 |
|
427 | 435 | if (new_bucket>metap->hashm_highmask) |
@@ -456,6 +464,9 @@ _hash_expandtable(Relation rel, Buffer metabuf) |
456 | 464 | if (!_hash_try_getlock(rel,start_nblkno,HASH_EXCLUSIVE)) |
457 | 465 | elog(PANIC,"could not get lock on supposedly new bucket"); |
458 | 466 |
|
| 467 | +/* Done mucking with metapage */ |
| 468 | +END_CRIT_SECTION(); |
| 469 | + |
459 | 470 | /* |
460 | 471 | * Copy bucket mapping info now; this saves re-accessing the meta page |
461 | 472 | * inside _hash_splitbucket's inner loop. Note that once we drop the |
|