Horton

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

Dimitrios Apostolou <jimis@gmx.net>

View thread
From: Dimitrios Apostolou <jimis@gmx.net>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tomas Vondra <tomas@vondra.me>, pgsql-hackers@lists.postgresql.org, Andres Freund <andres@anarazel.de>, Melanie Plageman <melanieplageman@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, David Rowley <dgrowleyml@gmail.com>
Date: 2025-07-28T20:41:54Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add file_extend_method=posix_fallocate,write_zeros.

  2. Add smgrzeroextend(), FileZero(), FileFallocate()

On Friday 2025-07-11 00:45, Thomas Munro wrote:

> On Fri, Jul 11, 2025 at 5:39 AM Dimitrios Apostolou <jimis@gmx.net> wrote:
>>> I applied the patch on PostgreSQL v17 and am testing it now. I chose
>>> ftruncate method and I see ftruncate in action using strace while doing
>>> pg_restore of a big database. Nothing unexpected has happened so far. I also
>>> verified that files are being compressed, obeying Btrfs's mount option
>>> compress=zstd.
>>>
>>> Thanks for the patch! What are the odds of commiting it to v17?
>>
>> Ping. :-)
>> Patch behaves good for me. Any chance of applying it and backporting it?
>
> Yeah, this seems to make sense, as it is a pretty bad regression for
> people who are counting on BTRFS compression for their large database.
> Not so sure about the threshold bit -- I'd probably leave that out of
> the backport in the interest of stable branch-minimalism.  Anyone have
> any better ideas, better naming, or objections?

What is the right process to not lose track of this? Should I create a 
commitfest entry? Should I keep pinging every couple of weeks? Or is the 
patch queued somewhere and I have to wait patiently? If July commitfest 
passes, could it miss the next release?

Please forgive my ignorance, but I'm lost with respect to the postgresql 
development process. I also have some patches or suggestions of my own 
that struggle to get feedback, so I'd appreciate any tips regarding the 
development process.


Thank you,
Dimitris