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

From Thomas Munro
Subject Re: pg_waldump: support decoding of WAL inside tarfile
Date
Msg-id CA+hUKGK-GaHRh5mO0WKWO6MiL-iJ=+j_vVg4f-3pQXATNfRC2Q@mail.gmail.com
Whole thread
In response to Re: pg_waldump: support decoding of WAL inside tarfile  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_waldump: support decoding of WAL inside tarfile
List pgsql-hackers
On Sun, Mar 29, 2026 at 11:37 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
> > However ... I do not find any indication in the GNU tar docs
> > that it produces sparse files by default.  It looks like you
> > need to say -S/--sparse to make that happen.  Maybe you have
> > a version that's been hacked to make that the default?
>
> Bleah.  Digging in the man pages at freebsd.org, I read
>
>     --read-sparse
>                (c, r, u modes only) Read sparse file  information  from  disk.
>                This  is the reverse of --no-read-sparse and the default behav-
>                ior.
>
> 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 looks like to make this test stable on modern FreeBSD,
> we need to see if tar accepts --no-read-sparse and use that
> switch if so.

Yeah.  Here's my attempt at perl.

I think your Mac probably has a similar tar program BTW... but apfs
probably doesn't go around making holes visible to lseek()
automatically or at least as eagerly as my ZFS system.

Attachment

pgsql-hackers by date:

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