Maintain valid md.c state when FileClose() fails.

nmisch · nmisch · commit cb977424532f · 2020-01-10T18:31:26.000-08:00
FileClose() failure ordinarily causes a PANIC. Suppose the user disables that PANIC via data_sync_retry=on. After mdclose() issued a FileClose() that failed, calls into md.c raised SIGSEGV. This fix adds repalloc() calls during mdclose(); update a comment about ignoring repalloc() cost. The rate of relation segment count change is a minor factor; more relevant to overall performance is the rate of mdclose() and subsequent re-opening of segments. Back-patch to v10, where commit 45e191e introduced the bug. Reviewed by Kyotaro Horiguchi. Discussion: https://postgr.es/m/20191222091930.GA1280238@rfd.leadboat.com
diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c
@@ -639,18 +639,10 @@ mdclose(SMgrRelation reln, ForkNumber forknum)
 	{
 		MdfdVec    *v = &reln->md_seg_fds[forknum][nopensegs - 1];
 
-		/* if not closed already */
-		if (v->mdfd_vfd >= 0)
-		{
-			FileClose(v->mdfd_vfd);
-			v->mdfd_vfd = -1;
-		}
-
+		FileClose(v->mdfd_vfd);
+		_fdvec_resize(reln, forknum, nopensegs - 1);
 		nopensegs--;
 	}
-
-	/* resize just once, avoids pointless reallocations */
-	_fdvec_resize(reln, forknum, 0);
 }
 
 /*
@@ -1774,10 +1766,10 @@ _fdvec_resize(SMgrRelation reln,
 	else
 	{
 		/*
-		 * It doesn't seem worthwhile complicating the code by having a more
-		 * aggressive growth strategy here; the number of segments doesn't
-		 * grow that fast, and the memory context internally will sometimes
-		 * avoid doing an actual reallocation.
+		 * It doesn't seem worthwhile complicating the code to amortize
+		 * repalloc() calls.  Those are far faster than PathNameOpenFile() or
+		 * FileClose(), and the memory context internally will sometimes avoid
+		 * doing an actual reallocation.
 		 */
 		reln->md_seg_fds[forknum] =
 			repalloc(reln->md_seg_fds[forknum],
