Re: pg_waldump: support decoding of WAL inside tarfile

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