public inbox for [email protected]
help / color / mirror / Atom feedBug: mdunlinkfiletag unlinks mainfork seg.0 instead of indicated fork+segment
2+ messages / 2 participants
[nested] [flat]
* Bug: mdunlinkfiletag unlinks mainfork seg.0 instead of indicated fork+segment
@ 2024-12-20 22:41 Matthias van de Meent <[email protected]>
2026-05-18 16:42 ` Re: Bug: mdunlinkfiletag unlinks mainfork seg.0 instead of indicated fork+segment surya poondla <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Matthias van de Meent @ 2024-12-20 22:41 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>; Robert Haas <[email protected]>; Dilip Kumar <[email protected]>
Hi,
I noticed that the MD smgr internals misbehave when unlink requests
for specific forks or specific segments are sent through SyncOps, as
it currently always unlinks segment 0 of the main fork, even if only a
different fork and/or segment was requested.
While probably not extremely critical, it seems bad to not unlink the
right segment while in recovery, so here's a patch that unlinks the
exact requested files.
The unlinking of forks in the FileTag infrastructure has been broken
since b0a55e43 in PG16, while a segment number other than 0 has never
been unlinked (at least not since the introduction of the system with
3eb77eba in PG12). However, extensions may still make use of this and
incorrectly assume that only the requested file of the requested fork
's segment will be unlinked, when it actually unlinks data from the
main fork.
The attached fixes that for PG16+. PG13-15 will take a little bit more
effort due to code changes in PG16; though it'd probably still require
a relatively minor change.
Kind regards,
Matthias van de Meent.
Neon (https://neon.tech)
Attachments:
[application/octet-stream] v1-0001-MD-smgr-Unlink-the-requested-file-segment-not-mai.patch (2.1K, 2-v1-0001-MD-smgr-Unlink-the-requested-file-segment-not-mai.patch)
download | inline diff:
From e7818a6579d644eb1caeedd6edb3740ae796f718 Mon Sep 17 00:00:00 2001
From: Matthias van de Meent <[email protected]>
Date: Fri, 20 Dec 2024 19:25:16 +0100
Subject: [PATCH v1] MD smgr: Unlink the requested file segment, not main fork
segment 0
While it seems like we only unlink segment 0 of any fork, it's
better to just comply with the request, instead of ignoring the
provided information.
Backpatch: 13, the oldest supported release.
---
src/backend/storage/smgr/md.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c
index cc8a80ee96..3175ec252a 100644
--- a/src/backend/storage/smgr/md.c
+++ b/src/backend/storage/smgr/md.c
@@ -133,6 +133,8 @@ static void _fdvec_resize(SMgrRelation reln,
int nseg);
static char *_mdfd_segpath(SMgrRelation reln, ForkNumber forknum,
BlockNumber segno);
+static char *_mdfd_segpath_rflb(RelFileLocatorBackend reln, ForkNumber forknum,
+ BlockNumber segno);
static MdfdVec *_mdfd_openseg(SMgrRelation reln, ForkNumber forknum,
BlockNumber segno, int oflags);
static MdfdVec *_mdfd_getseg(SMgrRelation reln, ForkNumber forknum,
@@ -1535,11 +1537,18 @@ _fdvec_resize(SMgrRelation reln,
*/
static char *
_mdfd_segpath(SMgrRelation reln, ForkNumber forknum, BlockNumber segno)
+{
+ return _mdfd_segpath_rflb(reln->smgr_rlocator, forknum, segno);
+}
+
+static char *
+_mdfd_segpath_rflb(RelFileLocatorBackend reln, ForkNumber forknum,
+ BlockNumber segno)
{
char *path,
*fullpath;
- path = relpath(reln->smgr_rlocator, forknum);
+ path = relpath(reln, forknum);
if (segno > 0)
{
@@ -1810,9 +1819,14 @@ int
mdunlinkfiletag(const FileTag *ftag, char *path)
{
char *p;
+ RelFileLocatorBackend rlfb = {
+ .locator = ftag->rlocator,
+ .backend = INVALID_PROC_NUMBER,
+ };
+ Assert(ftag->segno == 0);
/* Compute the path. */
- p = relpathperm(ftag->rlocator, MAIN_FORKNUM);
+ p = _mdfd_segpath_rflb(rlfb, ftag->forknum, ftag->segno);
strlcpy(path, p, MAXPGPATH);
pfree(p);
--
2.45.2
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Bug: mdunlinkfiletag unlinks mainfork seg.0 instead of indicated fork+segment
2024-12-20 22:41 Bug: mdunlinkfiletag unlinks mainfork seg.0 instead of indicated fork+segment Matthias van de Meent <[email protected]>
@ 2026-05-18 16:42 ` surya poondla <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: surya poondla @ 2026-05-18 16:42 UTC (permalink / raw)
To: solai v <[email protected]>; +Cc: Matthias van de Meent <[email protected]>; PostgreSQL Hackers <[email protected]>; Robert Haas <[email protected]>; Dilip Kumar <[email protected]>
Hi Solai,
Thanks for testing and confirming.
Sounds good regarding your comment suggestion.
Regards,
Surya Poondla
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-05-18 16:42 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-12-20 22:41 Bug: mdunlinkfiletag unlinks mainfork seg.0 instead of indicated fork+segment Matthias van de Meent <[email protected]>
2026-05-18 16:42 ` surya poondla <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox