On Mon, Mar 30, 2026 at 11:23 AM Tom Lane <[email protected]> wrote:

Thomas Munro <[email protected]> writes:

Anyway, given the defaults, GNU tar + ZFS/BTRFS users must be pretty
unlikely to hit this in the wild, and the symptom is a confusing error
in a maintenance tool, not corruption, so I don't think this is a big
deal.  I might still try teaching the astreamer code to understand PAX
1.0 when it sees it in the next cycle though, for the benefit of
FreeBSD users.

I agree that this isn't too critical if the effects are confined to
pg_waldump.  I believe that pg_basebackup and pg_verifybackup also use
astreamer_tar.c, but it's not clear to me if they'd ever be asked to
parse files made by tar(1) and not by our own sparseness-ignorant
tar-writing code.  If they can be, that'd be a higher-priority reason
to fill in this gap.

I pushed the workaround for the test.

It occurred to me this morning that we probably shouldn't run this test on Windows, and if we do we shouldn't be using /dev/null (the Windows equivalent of which is just "nul"). The simplest fix would just be to add a "!$windows_os" to the if test.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com