diff options
| author | Noah Misch <noah@leadboat.com> | 2020-01-10 18:31:22 -0800 |
|---|---|---|
| committer | Noah Misch <noah@leadboat.com> | 2020-01-10 18:31:26 -0800 |
| commit | cb977424532f20fae65f2e58ac901286a2482b24 (patch) | |
| tree | 2205c796d4ecf46cc37d78150765b151b328a4a7 /src | |
| parent | 7b84ff33a14095b6252edbee686edf93ac9c8d1b (diff) | |
| download | postgresql-cb977424532f20fae65f2e58ac901286a2482b24.tar.gz postgresql-cb977424532f20fae65f2e58ac901286a2482b24.zip | |
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
45e191e3aa62d47a8bc1a33f784286b2051f45cb introduced the bug.
Reviewed by Kyotaro Horiguchi.
Discussion: https://postgr.es/m/20191222091930.GA1280238@rfd.leadboat.com
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/storage/smgr/md.c | 20 |
1 files changed, 6 insertions, 14 deletions
diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c index d2a9dfd8b28..feb69b3b9f3 100644 --- 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], |