On Tue, 3 Jun 2025, Thomas Munro wrote:
On Mon, Jun 2, 2025 at 10:14 PM Dimitrios Apostolou wrote:
On Sun, 1 Jun 2025, Thomas Munro wrote:
Or for a completely different approach: I wonder if ftruncate() would
be more efficient on COW systems anyway. The minimum thing we need is
for the file
On Sun, Jun 1, 2025 at 02:00:17AM +1200, Thomas Munro wrote:
> 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 o
On Mon, Jun 2, 2025 at 10:14 PM Dimitrios Apostolou wrote:
> On Sun, 1 Jun 2025, Thomas Munro wrote:
> > Or for a completely different approach: I wonder if ftruncate() would
> > be more efficient on COW systems anyway. The minimum thing we need is
> > for the file system to remember the new size
On Sun, 1 Jun 2025, Thomas Munro wrote:
Or for a completely different approach: I wonder if ftruncate() would
be more efficient on COW systems anyway. The minimum thing we need is
for the file system to remember the new size, 'cause, erm, we don't.
All the rest is probably a waste of cycles, si
On Sat, May 31, 2025 at 4:33 PM Tomas Vondra wrote:
>
> On 5/31/25 16:00, Thomas Munro wrote:
> > On Fri, May 30, 2025 at 3:58 AM Dimitrios Apostolou wrote:
> >> All I'm saying is that this is a regression for PostgreSQL users that keep
> >> tablespaces on compressed Btrfs. What could be done fro
Thomas Munro writes:
> It's slightly tricky to get smgr to behave differently because of the
> contents of a system catalogue!
The mere thought makes me blanch. I'm okay with the GUC part,
but I do not think we should put in 0002 --- the odds of
causing serious problems greatly outweigh the valu
On 5/31/25 16:00, Thomas Munro wrote:
> On Fri, May 30, 2025 at 3:58 AM Dimitrios Apostolou 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 fal
Or for a completely different approach: I wonder if ftruncate() would
be more efficient on COW systems anyway. The minimum thing we need is
for the file system to remember the new size, 'cause, erm, we don't.
All the rest is probably a waste of cycles, since they reserve real
space (or fail to) la
On Fri, May 30, 2025 at 3:58 AM Dimitrios Apostolou 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 c
On Wed, 28 May 2025, Tomas Vondra wrote:
Isn't guaranteeing success of a write a general issue with compressed
filesystem? Why is posix_fallocate() any special in this regard?
Shouldn't the filesystem be defensive and assume the data is not
compressible? Or maybe just return EOPNOTSUPP when in d
On 5/28/25 16:22, Dimitrios Apostolou wrote:
> Hello, sorry for mass sending this, but I didn't get any response to my
> first email [1] so I'm now CC'ing the commit's 4d330a6 [2] author and
> the reviewers. I think it's an important issue, because I need to
> custom-compile postgresql to have wh
Hello, sorry for mass sending this, but I didn't get any response to my
first email [1] so I'm now CC'ing the commit's 4d330a6 [2] author and the
reviewers. I think it's an important issue, because I need to
custom-compile postgresql to have what I had before: a transparently
compressed databas
12 matches
Mail list logo
