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

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
45e191e3aa introduced the bug.

Reviewed by Kyotaro Horiguchi.

Discussion: https://postgr.es/m/20191222091930.GA1280238@rfd.leadboat.com
This commit is contained in:
Noah Misch 2020-01-10 18:31:22 -08:00
parent 2696434b7f
commit 2e86e154da
1 changed files with 6 additions and 14 deletions

View File

@ -638,18 +638,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);
}
/*
@ -1773,10 +1765,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],