On Tue, 15 Oct 2024 at 04:50, px shi <spxlyy...@gmail.com> wrote: >> >> You will find other places where relpathperm() is called without having >> a FileTag structure available, e.g. ReorderBufferProcessTXN(). > > > I apologize for the confusion. What I meant to say is that in the > mdunlinkfiletag() function, the forknum is currently hardcoded as > MAIN_FORKNUM when calling relpathperm(). While mdunlinkfiletag currently only > handles MAIN_FORKNUM, wouldn’t it be more flexible to retrieve the forknum > from the ftag structure instead?
I just noticed this mail thread as I was searching the archives for other mentions of `mdunlinkfiletag` when doing some more digging on uses of that function, to back my own bug report of what looks like the same issue. See [0]. As was explained to me by Thomas, the reason why MAIN_FORKNUM is hardcoded here (and why ftag.segno is also ignored) is that this code is only ever reached for FileTag values with forknum=MAIN_FORKNUM (and segno is also always 0) with the code in Postgres' repository. The patch proposed in [0] is supposed to make that more clear to developers. I suspect the code will be further updated to include the correct fork number and segment number when there is a need to unlink non-MAIN_FORKNUM or non-segno=0 files in mdunlinkfiletag. Kind regards, Matthias van de Meent [0] https://www.postgresql.org/message-id/flat/CAEze2WiWt%2B9%2BOnqW1g9rKz0gqxymmt%3Doe6pKAEDrutdfpDMpTw%40mail.gmail.com
