hash-avoid-heavyweight-metapage-locks-v2.patch

diff --git a/src/backend/access/hash/README b/src/backend/access/hash/README
index 4082581..2652cae 100644
--- a/src/backend/access/hash/README
+++ b/src/backend/access/hash/README
@@ -187,19 +187,21 @@ track of available overflow pages.
 
 The reader algorithm is:
 
-	read/sharelock meta page
-    loop:
+	pin meta page and take buffer content lock in shared mode
+	loop:
 		compute bucket number for target hash key
-		release meta page
+		release meta page buffer content lock
 		if (correct bucket page is already locked)
 			break
 		release any existing bucket page lock (if a concurrent split happened)
-		share-lock bucket page
+		take heavyweight bucket lock
+		retake meta page buffer content lock in shared mode
 -- then, per read request:
-	read/sharelock current page of bucket
+	release pin on metapage
+	read current page of bucket and take shared buffer content lock
 		step to next page if necessary (no chaining of locks)
 	get tuple
-	release current page
+	release buffer content lock and pin on current page
 -- at scan shutdown:
 	release bucket share-lock
 
@@ -225,24 +227,26 @@ as it was before.
 
 The insertion algorithm is rather similar:
 
-	read/sharelock meta page
-    loop:
+	pin meta page and take buffer content lock in shared mode
+	loop:
 		compute bucket number for target hash key
-		release meta page
+		release meta page buffer content lock
 		if (correct bucket page is already locked)
 			break
 		release any existing bucket page lock (if a concurrent split happened)
-		share-lock bucket page
+		take heavyweight bucket lock in shared mode
+		retake meta page buffer content lock in shared mode
 -- (so far same as reader)
-	read/exclusive-lock current page of bucket
+	release pin on metapage
+	pin current page of bucket and take exclusive buffer content lock
 	if full, release, read/exclusive-lock next page; repeat as needed
 	>> see below if no space in any page of bucket
 	insert tuple at appropriate place in page
-	write/release current page
-	release bucket share-lock
-	read/exclusive-lock meta page
+	mark current page dirty and release buffer content lock and pin
+	release heavyweight share-lock
+	pin meta page and take buffer content lock in shared mode
 	increment tuple count, decide if split needed
-	write/release meta page
+	mark meta page dirty and release buffer content lock and pin
 	done if no split needed, else enter Split algorithm below
 
 To speed searches, the index entries within any individual index page are
@@ -267,17 +271,15 @@ index is overfull (has a higher-than-wanted ratio of tuples to buckets).
 The algorithm attempts, but does not necessarily succeed, to split one
 existing bucket in two, thereby lowering the fill ratio:
 
-	exclusive-lock page 0 (assert the right to begin a split)
-	read/exclusive-lock meta page
+	pin meta page and take buffer content lock in exclusive mode
 	check split still needed
-	if split not needed anymore, drop locks and exit
+	if split not needed anymore, drop buffer content lock and pin and exit
 	decide which bucket to split
 	Attempt to X-lock old bucket number (definitely could fail)
 	Attempt to X-lock new bucket number (shouldn't fail, but...)
-	if above fail, drop locks and exit
+	if above fail, drop locks and pin and exit
 	update meta page to reflect new number of buckets
-	write/release meta page
-	release X-lock on page 0
+	mark meta page dirty and release buffer content lock and pin
 	-- now, accesses to all other buckets can proceed.
 	Perform actual split of bucket, moving tuples as needed
 	>> see below about acquiring needed extra space
@@ -313,20 +315,20 @@ go-round.
 The fourth operation is garbage collection (bulk deletion):
 
 	next bucket := 0
-	read/sharelock meta page
+	pin metapage and take buffer content lock in exclusive mode
 	fetch current max bucket number
-	release meta page
+	release meta page buffer content lock and pin
 	while next bucket <= max bucket do
 		Acquire X lock on target bucket
 		Scan and remove tuples, compact free space as needed
 		Release X lock
 		next bucket ++
 	end loop
-	exclusive-lock meta page
+	pin metapage and take buffer content lock in exclusive mode
 	check if number of buckets changed
-	if so, release lock and return to for-each-bucket loop
+	if so, release content lock and pin and return to for-each-bucket loop
 	else update metapage tuple count
-	write/release meta page
+	mark meta page dirty and release buffer content lock and pin
 
 Note that this is designed to allow concurrent splits.  If a split occurs,
 tuples relocated into the new bucket will be visited twice by the scan,
@@ -357,25 +359,25 @@ overflow page to the free pool.
 
 Obtaining an overflow page:
 
-	read/exclusive-lock meta page
+	take metapage content lock in exclusive mode
 	determine next bitmap page number; if none, exit loop
-	release meta page lock
-	read/exclusive-lock bitmap page
+	release meta page content lock
+	pin bitmap page and take content lock in exclusive mode
 	search for a free page (zero bit in bitmap)
 	if found:
 		set bit in bitmap
-		write/release bitmap page
-		read/exclusive-lock meta page
+		mark bitmap page dirty and release content lock
+		take metapage buffer content lock in exclusive mode
 		if first-free-bit value did not change,
-			update it and write meta page
-		release meta page
+			update it and mark meta page dirty
+		release meta page buffer content lock
 		return page number
 	else (not found):
-	release bitmap page
+	release bitmap page buffer content lock
 	loop back to try next bitmap page, if any
 -- here when we have checked all bitmap pages; we hold meta excl. lock
 	extend index to add another overflow page; update meta information
-	write/release meta page
+	mark meta page dirty and release buffer content lock
 	return page number
 
 It is slightly annoying to release and reacquire the metapage lock
@@ -425,17 +427,17 @@ algorithm is:
 
 	delink overflow page from bucket chain
 	(this requires read/update/write/release of fore and aft siblings)
-	read/share-lock meta page
+	pin meta page and take buffer content lock in shared mode
 	determine which bitmap page contains the free space bit for page
-	release meta page
-	read/exclusive-lock bitmap page
+	relase meta page buffer content lock
+	pin bitmap page and take buffer content lock in exclusie mode
 	update bitmap bit
-	write/release bitmap page
+	mark bitmap page dirty and release buffer content lock and pin
 	if page number is less than what we saw as first-free-bit in meta:
-	read/exclusive-lock meta page
+	retake meta page buffer content lock in exclusive mode
 	if page number is still less than first-free-bit,
-		update first-free-bit field and write meta page
-	release meta page
+		update first-free-bit field and mark meta page dirty
+	release meta page buffer content lock and pin
 
 We have to do it this way because we must clear the bitmap bit before
 changing the first-free-bit field (hashm_firstfree).  It is possible that
diff --git a/src/backend/access/hash/hashpage.c b/src/backend/access/hash/hashpage.c
index c0b6eb0..3d067e7 100644
--- a/src/backend/access/hash/hashpage.c
+++ b/src/backend/access/hash/hashpage.c
@@ -559,12 +559,6 @@ _hash_expandtable(Relation rel, Buffer metabuf)
 	if (_hash_has_active_scan(rel, old_bucket))
 		goto fail;
 
-	/*
-	 * It's normally a bad idea to grab a heavyweight lock while holding
-	 * a buffer content lock, both because of deadlock risk and because
-	 * content locks should be held only briefly.  But since we are only
-	 * trylocking here it should be OK.
-	 */
 	if (!_hash_try_getlock(rel, start_oblkno, HASH_EXCLUSIVE))
 		goto fail;
 
@@ -581,12 +575,6 @@ _hash_expandtable(Relation rel, Buffer metabuf)
 	if (_hash_has_active_scan(rel, new_bucket))
 		elog(ERROR, "scan in progress on supposedly new bucket");
 
-	/*
-	 * It's normally a bad idea to grab a heavyweight lock while holding
-	 * a buffer content lock, both because of deadlock risk and because
-	 * content locks should be held only briefly.  But since we are only
-	 * trylocking here it should be OK.
-	 */
 	if (!_hash_try_getlock(rel, start_nblkno, HASH_EXCLUSIVE))
 		elog(ERROR, "could not get lock on supposedly new bucket");