Tomas Vondra <tomas@vondra.me> writes:
> On 4/2/26 19:43, Tom Lane wrote:
>> Tomas Vondra <tomas@vondra.me> writes:
>>> Maybe there's something special about OpenSUSE?
>> Apparently its version of "tar" will produce pax-extended files
>> at the drop of a hat. I have an OpenSUSE image around here
>> somewhere, will see if I can reproduce this. But while I'm
>> asking, what filesystem are those animals running on top of?
> btrfs
Yup, so capable of making sparse WAL files. I can reproduce the
problem here, and what I see is
> tar --version
tar (GNU tar) 1.34
Copyright (C) 2021 Free Software Foundation, Inc.
...
> tar -?
...
-H, --format=FORMAT create archive of the given format
FORMAT is one of the following:
gnu GNU tar 1.13.x format
oldgnu GNU format as per tar <= 1.12
pax POSIX 1003.1-2001 (pax) format
posix same as pax
ustar POSIX 1003.1-1988 (ustar) format
v7 old V7 tar format
...
*This* tar defaults to:
--format=posix -f- -b20 --quoting-style=escape --rmt-command=/usr/bin/rmt
--rsh-command=/usr/bin/ssh
So there you have it: pax format by default. This is unlike what
I see on RHEL or Fedora:
...
*This* tar defaults to:
--format=gnu -f- -b20 --quoting-style=escape --rmt-command=/etc/rmt
--rsh-command=/usr/bin/ssh
So it looks like we need a switch hack similar to what we did for
BSD tar, but injecting "--format=gnu" (or perhaps "--format=ustar"?)
if the tar program will take that.
Interestingly, pg_verifybackup's t/003_corruption.pl test also fails
with the same issue, so apparently this platform is even more
aggressive about sparse-ifying files than Thomas' FreeBSD box.
I wonder how come we managed to pass that test case before on
these machines.
I'm inclined to push the logic for selecting these tar options
into some common subroutine in Test::Utils, rather than having
two copies (and maybe more later).
regards, tom lane
