On 2026-03-31 Tu 10:05 PM, Thomas Munro wrote:
On Mon, Mar 30, 2026 at 11:23 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> 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
