Re: [PING] fallocate() causes btrfs to never compress postgresql files

On Thu, Oct 30, 2025 at 4:56 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Wed, Oct 29, 2025 at 4:31 AM Dimitrios Apostolou <jimis@gmx.net> wrote:
> > Sorry to ping again, but was there a conclusion reached regarding adding the new file_extend_method setting?
>
> No objections appeared, so the conclusion I am drawing is that we
> should do this,

Hi Thomas,

+1 to this GUCs as this would also help the nearby thread with XFS
mysteries which are not fully solved [1]. Since the latest message in
that discussion, I'm aware of at least one additional report of XFS
failing at fallocate() with free space too, but without any details
from the OS support vendor why that happened, so this $patch could be
also used to workaround that problem too.

Just nitpicking:

> and back-patch it into 17 for the upcoming release.
> It is working as expected on my ZFS system in light testing.  Rebasing
> and figuring out where to add the missing documentation for last
> chance review...

Why just 17? (wasn't fallocate() introduced in 16? 4d330a61bb19 and
31966b151e6ab are from Apr 2023, while 16 was released on Sep 2023)

From other things, I was wondering about this:

> PGC_USERSET

QQ: Do we really want to have those two GUCs to be alterable like that
by anyone? The alternative would be like let's say PGC_SIGHUP? (on one
end it's flexible, but are there any downsides to this as it stands
out in 0001?). I've checked others and io_workers is PGC_SIGHUP
(understandable), but we also have io_combine_limit &&
effective_io_concurrency with PGC_USERSET. I'm just wondering if it
would be sane to have one backend doing I/O with fallocate() and other
just writing using pwrite(). One could argue you could be writing to
two different filesystems with two different users...

-J.

[1] -
https://www.postgresql.org/message-id/flat/CADofcAV8xu3hCNHq7-7x56KrP9rD6%3DA04%3DqjTr3nETh-gptF8w%40mail.gmail.com