Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit0e758ae

Browse files
committed
Fix failure to remove non-first segments of temporary tables.
Commit4ab5dae broke mdunlinkfork's logic for removing additionalsegments of a multi-gigabyte table, because it neglected to advance"segno" after unlinking the first segment, in the code path where itchooses to unlink that one immediately. Then the main remove loopgets ENOENT at segment zero and figures it's done, so we never removewhatever additional segments might exist.The main problem here is with large temporary tables, but WAL replayof a drop of a large regular table would also fail to remove extrasegments. The third case where this path is taken is for non-mainforks; but I doubt it matters for those since they probably neverexceed 1GB.The simplest fix is just to increment segno after that unlink().(Probably this logic could do with a more thorough rethink, but notwith mere hours to go before 15.1 wraps.)While here, also fix an incautious assumption thatregister_forget_request cannot change errno. I don't think thatthat has any really bad consequences, as we'd end up trying to unlinkthe zero'th segment either way, but it greatly complicates reasoningabout what could happen here. Also make a couple of other cosmeticfixes.Per bug #17679 from Balazs Szilfai. Back-patch into v15, as thefaulty patch was.Discussion:https://postgr.es/m/17679-1095d04450cf6a6e@postgresql.org
1 parenta1a7bb8 commit0e758ae

File tree

1 file changed

+12
-6
lines changed
  • src/backend/storage/smgr

1 file changed

+12
-6
lines changed

‎src/backend/storage/smgr/md.c

Lines changed: 12 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -330,11 +330,15 @@ mdunlinkfork(RelFileLocatorBackend rlocator, ForkNumber forknum, bool isRedo)
330330
{
331331
if (!RelFileLocatorBackendIsTemp(rlocator))
332332
{
333+
intsave_errno;
334+
333335
/* Prevent other backends' fds from holding on to the disk space */
334336
ret=do_truncate(path);
335337

336338
/* Forget any pending sync requests for the first segment */
339+
save_errno=errno;
337340
register_forget_request(rlocator,forknum,0/* first seg */ );
341+
errno=save_errno;
338342
}
339343
else
340344
ret=0;
@@ -347,6 +351,7 @@ mdunlinkfork(RelFileLocatorBackend rlocator, ForkNumber forknum, bool isRedo)
347351
ereport(WARNING,
348352
(errcode_for_file_access(),
349353
errmsg("could not remove file \"%s\": %m",path)));
354+
segno++;
350355
}
351356
}
352357
else
@@ -359,21 +364,22 @@ mdunlinkfork(RelFileLocatorBackend rlocator, ForkNumber forknum, bool isRedo)
359364
* segment later, rather than now.
360365
*
361366
* If we're performing a binary upgrade, the dangers described in the
362-
* header comments for mdunlink() do not exist, since after a crash
363-
*oreven a simple ERROR, the upgrade fails and the whole new cluster
367+
* header comments for mdunlink() do not exist, since after a crash or
368+
* even a simple ERROR, the upgrade fails and the whole new cluster
364369
* must be recreated from scratch. And, on the other hand, it is
365-
* important to remove the files from disk immediately, because we
366-
*maybe about to reuse the same relfilenumber.
370+
* important to remove the files from disk immediately, because we may
371+
* be about to reuse the same relfilenumber.
367372
*/
368373
if (!IsBinaryUpgrade)
369374
{
370375
register_unlink_segment(rlocator,forknum,0/* first seg */ );
371-
++segno;
376+
segno++;
372377
}
373378
}
374379

375380
/*
376-
* Delete any additional segments.
381+
* Delete any remaining segments (we might or might not have dealt with
382+
* the first one above).
377383
*/
378384
if (ret >=0)
379385
{

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp