Repair a bunch of problems in md.c. This builds on Hiroshi's

insight that RelationFlushRelation ought to invoke smgrclose, and that the
way to make that work is to ensure that mdclose doesn't fail if the relation
is already closed (or unlinked, if we are looking at a DROP TABLE).  While
I was testing that, I was able to identify several problems that we had
with multiple-segment relations.  The system is now able to do initdb and
pass the regression tests with a very small segment size (I had it set to
64Kb per segment for testing).  I don't believe that ever worked before.
File descriptor leaks seem to be gone too.
I have partially addressed the concerns we had about mdtruncate(), too.
On a Win32 or NFS filesystem it is not possible to unlink a file that
another backend is holding open, so what md.c now does is to truncate
unwanted files to zero length before trying to unlink them.  The other
backends will be forced to close their open files by relation cache
invalidation --- but I think it would take considerable work to make
that happen before vacuum truncates the relation rather than after.
Leaving zero-length files lying around seems a usable compromise.

src/backend/storage/smgr/smgr.c

@@ -10,7 +10,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/storage/smgr/smgr.c,v 1.28 1999/07/17 20:17:49 momjian Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/storage/smgr/smgr.c,v 1.29 1999/09/02 02:57:49 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -191,12 +191,11 @@ smgropen(int16 which, Relation reln)
 /*
  *	smgrclose() -- Close a relation.
  *
- *		NOTE: mdclose frees fd vector! It may be re-used for other relation!
- *		reln should be flushed from cache after closing !..
- *		Currently, smgrclose is calling by
- *		relcache.c:RelationPurgeLocalRelation() only.
- *		It would be nice to have smgrfree(), but because of
- *		smgrclose is called from single place...		- vadim 05/22/97
+ *		NOTE: underlying manager should allow case where relation is
+ *		already closed.  Indeed relation may have been unlinked!
+ *		This is currently called only from RelationFlushRelation() when
+ *		the relation cache entry is about to be dropped; could be doing
+ *		simple relation cache clear, or finishing up DROP TABLE.
  *		
  *		Returns SM_SUCCESS on success, aborts on failure.
  */

src/backend/utils/cache/relcache.c

@@ -7,7 +7,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/utils/cache/relcache.c,v 1.67 1999/07/17 20:18:02 momjian Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/utils/cache/relcache.c,v 1.68 1999/09/02 02:57:50 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1256,9 +1256,13 @@ RelationFlushRelation(Relation *relationPtr,
 	if (!onlyFlushReferenceCountZero ||
 		RelationHasReferenceCountZero(relation))
 	{
-
 		oldcxt = MemoryContextSwitchTo((MemoryContext) CacheCxt);
 
+		/* make sure smgr and lower levels close the relation's files,
+		 * if they weren't closed already
+		 */
+		smgrclose(DEFAULT_SMGR, relation);
+
 		RelationCacheDelete(relation);
 
 		FreeTupleDesc(relation->rd_att);
@@ -1515,17 +1519,6 @@ RelationPurgeLocalRelation(bool xactCommitted)
 			else
 				smgrunlink(DEFAULT_SMGR, reln);
 		}
-		else if (!IsBootstrapProcessingMode() && !(reln->rd_isnoname))
-
-			/*
-			 * RelationFlushRelation () below will flush relation
-			 * information from the cache. We must call smgrclose to flush
-			 * relation information from SMGR & FMGR, too. We assume that
-			 * for temp relations smgrunlink is already called by
-			 * heap_destroyr and we skip smgrclose for them.		  -
-			 * vadim 05/22/97
-			 */
-			smgrclose(DEFAULT_SMGR, reln);
 
 		reln->rd_myxactonly = FALSE;