On Fri, Jul 11, 2025 at 12:45 AM Thomas Munro
wrote:
> On Fri, Jul 11, 2025 at 5:39 AM Dimitrios Apostolou 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 dat
On Friday 2025-07-11 00:45, Thomas Munro wrote:
On Fri, Jul 11, 2025 at 5:39 AM Dimitrios Apostolou 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 unexpect
On Fri, Jul 11, 2025 at 5:39 AM Dimitrios Apostolou 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
> > verif
On Thu, 12 Jun 2025, Dimitrios Apostolou wrote:
On Mon, 9 Jun 2025, Thomas Munro wrote:
On Tue, Jun 3, 2025 at 1:58 AM Dimitrios Apostolou wrote:
This sounds like the best solution IMO. People can then experiment with
different settings and filesystems, and that way we also learn in the
On Mon, 9 Jun 2025, Thomas Munro wrote:
On Tue, Jun 3, 2025 at 1:58 AM Dimitrios Apostolou wrote:
This sounds like the best solution IMO. People can then experiment with
different settings and filesystems, and that way we also learn in the
process. Thank you for the effort and patches so far.
On Tue, Jun 3, 2025 at 1:58 AM Dimitrios Apostolou wrote:
> This sounds like the best solution IMO. People can then experiment with
> different settings and filesystems, and that way we also learn in the
> process. Thank you for the effort and patches so far.
OK, here's a basic patch to experimen
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
18 matches
Mail list logo
