Fix up rickety handling of relation-truncation interlocks.

Move rd_targblock, rd_fsm_nblocks, and rd_vm_nblocks from relcache to the smgr
relation entries, so that they will get reset to InvalidBlockNumber whenever
an smgr-level flush happens.  Because we now send smgr invalidation messages
immediately (not at end of transaction) when a relation truncation occurs,
this ensures that other backends will reset their values before they next
access the relation.  We no longer need the unreliable assumption that a
VACUUM that's doing a truncation will hold its AccessExclusive lock until
commit --- in fact, we can intentionally release that lock as soon as we've
completed the truncation.  This patch therefore reverts (most of) Alvaro's
patch of 2009-11-10, as well as my marginal hacking on it yesterday.  We can
also get rid of assorted no-longer-needed relcache flushes, which are far more
expensive than an smgr flush because they kill a lot more state.

In passing this patch fixes smgr_redo's failure to perform visibility-map
truncation, and cleans up some rather dubious assumptions in freespace.c and
visibilitymap.c about when rd_fsm_nblocks and rd_vm_nblocks can be out of
date.

1 files changed, 6 insertions, 5 deletions

diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c
index bb2498dedac..83915ba33d5 100644
--- a/src/backend/access/heap/hio.c
+++ b/src/backend/access/heap/hio.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/access/heap/hio.c,v 1.77 2010/01/02 16:57:34 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/access/heap/hio.c,v 1.78 2010/02/09 21:43:29 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -20,6 +20,7 @@
 #include "storage/bufmgr.h"
 #include "storage/freespace.h"
 #include "storage/lmgr.h"
+#include "storage/smgr.h"
 
 
 /*
@@ -126,7 +127,7 @@ ReadBufferBI(Relation relation, BlockNumber targetBlock,
  *
  *	HEAP_INSERT_SKIP_FSM is also useful for non-WAL-logged additions to a
  *	relation, if the caller holds exclusive lock and is careful to invalidate
- *	relation->rd_targblock before the first insertion --- that ensures that
+ *	relation's smgr_targblock before the first insertion --- that ensures that
  *	all insertions will occur into newly added pages and not be intermixed
  *	with tuples from other transactions.  That way, a crash can't risk losing
  *	any committed data of other transactions.  (See heap_insert's comments
@@ -206,7 +207,7 @@ RelationGetBufferForTuple(Relation relation, Size len,
 	else if (bistate && bistate->current_buf != InvalidBuffer)
 		targetBlock = BufferGetBlockNumber(bistate->current_buf);
 	else
-		targetBlock = relation->rd_targblock;
+		targetBlock = RelationGetTargetBlock(relation);
 
 	if (targetBlock == InvalidBlockNumber && use_fsm)
 	{
@@ -273,7 +274,7 @@ RelationGetBufferForTuple(Relation relation, Size len,
 		if (len + saveFreeSpace <= pageFreeSpace)
 		{
 			/* use this page as future insert target, too */
-			relation->rd_targblock = targetBlock;
+			RelationSetTargetBlock(relation, targetBlock);
 			return buffer;
 		}
 
@@ -377,7 +378,7 @@ RelationGetBufferForTuple(Relation relation, Size len,
 	 * current backend to make more insertions or not, which is probably a
 	 * good bet most of the time.  So for now, don't add it to FSM yet.
 	 */
-	relation->rd_targblock = BufferGetBlockNumber(buffer);
+	RelationSetTargetBlock(relation, BufferGetBlockNumber(buffer));
 
 	return buffer;
 }