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

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

> On Fri, Jul 11, 2025 at 5:39 AM Dimitrios Apostolou <jimis(at)gmx(dot)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