Re: pg_waldump: support decoding of WAL inside tarfile - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_waldump: support decoding of WAL inside tarfile
Date
Msg-id 1630755.1774739531@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_waldump: support decoding of WAL inside tarfile  (Tomas Vondra <tomas@vondra.me>)
Responses Re: pg_waldump: support decoding of WAL inside tarfile
List pgsql-hackers
Tomas Vondra <tomas@vondra.me> writes:
> On 3/28/26 23:36, Tom Lane wrote:
>> It's apparently been there and been default since FreeBSD 13.1.
>> This leads one to wonder how come BF member dikkop is managing
>> to run this test successfully.  I speculate that it's using a
>> filesystem type that doesn't do sparse files (cc'ing Vondra
>> for confirmation on that).

> It's running on ufs. But I think the explanation is very simple. We had
> a short power outage on Thursday, and the FreeBSD machine failed to boot
> properly after the power was restored. IIUC this test is new, right?

Not that new, it dates to b15c15139, about a week ago.

I've reproduced Thomas' failure on a local FreeBSD 15.0 image
using zfs, and confirmed that this cowboy hack fixes it:

diff --git a/src/bin/pg_waldump/t/001_basic.pl b/src/bin/pg_waldump/t/001_basic.pl
index 8bb8fa225f6..2904f4ef118 100644
--- a/src/bin/pg_waldump/t/001_basic.pl
+++ b/src/bin/pg_waldump/t/001_basic.pl
@@ -346,7 +346,7 @@ sub generate_archive
        # move into the WAL directory before archiving files
        my $cwd = getcwd;
        chdir($directory) || die "chdir: $!";
-       command_ok([$tar, $compression_flags, $archive, @files]);
+       command_ok([$tar, $compression_flags, $archive, '--no-read-sparse', @files]);
        chdir($cwd) || die "chdir: $!";
 }

Of course we can't commit that, but maybe somebody wants to
product-ize it.  (Not me, at least not today.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: pg_waldump: support decoding of WAL inside tarfile
Next
From: Daniel Gustafsson
Date:
Subject: Re: Changing the state of data checksums in a running cluster