diff options
| author | Andres Freund <andres@anarazel.de> | 2016-09-08 16:51:09 -0700 |
|---|---|---|
| committer | Andres Freund <andres@anarazel.de> | 2016-09-08 16:51:09 -0700 |
| commit | 769fd9d8e06bf862334a0e04134a3d2c665e5e5b (patch) | |
| tree | 8135446982b347ee9ebd1dcc4646bde75dc0c270 /src | |
| parent | 19acee8c5adb68b96222e41c084efbc9b31d397a (diff) | |
| download | postgresql-769fd9d8e06bf862334a0e04134a3d2c665e5e5b.tar.gz postgresql-769fd9d8e06bf862334a0e04134a3d2c665e5e5b.zip | |
Fix mdtruncate() to close fd.c handle of deleted segments.
mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting
it. That lead to a fd.c handle to a truncated file being kept open until
backend exit.
The issue appears to have been introduced way back in 1a5c450f3024ac5,
before that the handle was closed inside FileUnlink().
The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE
for temporary tables, truncate files in place (i.e. TRUNCATE itself is
not affected), and the relation has to be bigger than 1GB. The
consequences of a leaked fd.c handle aren't severe either.
Discussion: <20160908220748.oqh37ukwqqncbl3n@alap3.anarazel.de>
Backpatch: all supported releases
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/storage/smgr/md.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c index 12871429182..a94828b32c7 100644 --- a/src/backend/storage/smgr/md.c +++ b/src/backend/storage/smgr/md.c @@ -976,6 +976,7 @@ mdtruncate(SMgrRelation reln, ForkNumber forknum, BlockNumber nblocks) v = v->mdfd_chain; Assert(ov != reln->md_fd[forknum]); /* we never drop the 1st * segment */ + FileClose(ov->mdfd_vfd); pfree(ov); } else if (priorblocks + ((BlockNumber) RELSEG_SIZE) > nblocks) |