On Sat, May 31, 2025 at 4:33 PM Tomas Vondra <to...@vondra.me> wrote: > > On 5/31/25 16:00, Thomas Munro wrote: > > On Fri, May 30, 2025 at 3:58 AM Dimitrios Apostolou <ji...@gmx.net> wrote: > >> All I'm saying is that this is a regression for PostgreSQL users that keep > >> tablespaces on compressed Btrfs. What could be done from postgres, is to > >> provide a runtime setting for avoiding fallocate(), going instead through > >> the old code path. Idelly this would be an option per tablespace, but even > >> a global one is better than nothing. > > > > Here's an initial sketch of such a setting. Better name, design, > > words welcome. Would need a bit more work to cover temp tables too. > > It's slightly tricky to get smgr to behave differently because of the > > contents of a system catalogue! I couldn't think of a better way than > > exposing it as a flag that the buffer manager layer has to know about > > and compute earlier, but that also seems a bit strange, as fallocate > > is a highly md.c specific concern. Hmm. > > > > I find the definition of io_min_fallocate confusing, [..]
Thanks to Thomas for providing the patch, but - same here - but my take is that making it a GUC that takes a number for this instead of simply making it on/off switches makes it less more understandable. I think io_fallocate=on/off would be easier for the users. > > I suppose something like the 0001 part could be back-patched if this > > is considered a serious enough problem without other workarounds, so I > > did this in two steps. I wonder if there are good reasons to want to > > change the number on other file systems. I suppose it at least allows > > experimentation. > > Maybe. It'd need to get some of the 0002 bits too, ofc. > > I'm not sure we really want all these special GUC tailored for different > filesystems. We already have a few such GUCs, it's getting tricky to > know which ones to set / not set, and it also changes with the > filesystem version ... I personally don't know which ones to set, a lot > of the knowledge is somewhat outdated I think. Well, XFS also got quite several reports of regressions due to fallocate() being used [1], but there you could at least try to mitigate it. I don't think we'll be able to get away without it and the ginnie is already out of the bottle as the kernels are already widely used (well, in theory we could add capability that would help set some of those internal switches based on statfs(/path).fs_type, but realistically we would still need to have the ability to override anyway). -J. [1] - https://www.postgresql.org/message-id/CADofcAV8xu3hCNHq7-7x56KrP9rD6%3DA04%3DqjTr3nETh-gptF8w%40mail.gmail.com
