From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas@vondra.me>
cc: Thomas Munro <thomas.munro@gmail.com>, Andres Freund <andres@anarazel.de>,
        Michael Paquier <michael@paquier.xyz>,
        Andrew Dunstan <andrew@dunslane.net>, Amul Sul <sulamul@gmail.com>,
        Zsolt Parragi <zsolt.parragi@percona.com>,
        Robert Haas <robertmhaas@gmail.com>, Chao Li <li.evan.chao@gmail.com>,
        Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>,
        Fujii Masao <masao.fujii@gmail.com>,
        Jakub Wartak <jakub.wartak@enterprisedb.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_waldump: support decoding of WAL inside tarfile
In-reply-to: <63de1553-829a-488d-8ee0-976afb8dd32c@vondra.me>
References: <2250061.1774104346@sss.pgh.pa.us>
 <3341199.1774221191@sss.pgh.pa.us> <3424809.1774234940@sss.pgh.pa.us>
 <acIA8KKBTv-T53YG@paquier.xyz>
 <x2tknjejjouleunkqrvpnwn2tuulunybinycidefm3wmnsyhht@pw5uo3wrqx43>
 <CA+hUKGL2dppjO4o28ZY7n_LTWviKLAi-7KZ=tx5w2HGevCEYPA@mail.gmail.com>
 <1624716.1774736283@sss.pgh.pa.us> <1626907.1774737417@sss.pgh.pa.us>
 <97a382c0-1f19-4ea0-951f-e37e6abc34a3@vondra.me>
 <1630755.1774739531@sss.pgh.pa.us>
 <c3a2b730-9d90-4a66-ae5e-50f6d77922d6@vondra.me>
 <CA+hUKGJyvdyWMC-RW1njqevD-q_gTbFq+DyDiFpUJVaG+DY20w@mail.gmail.com>
 <1873141.1774823011@sss.pgh.pa.us>
 <CA+hUKG+Pqz5=YQG_=8ho0YsTfn2HWOsJQWqS4j0q8QQWweJP9w@mail.gmail.com>
 <3049460.1775067940@sss.pgh.pa.us> <CA+hUKGJv2hpjM!
 DwG31JSR7TfFUxNPPtQKMm6mHVVRMAT0XppBQ@mail.gmail.com>
 <3118179.1775092964@sss.pgh.pa.us>
 <CA+hUKG+-pn14s_tjEBO6YKHmc=uRhGVn=w2oM91KKnEUc7pH0Q@mail.gmail.com>
 <3565835.1775147392@sss.pgh.pa.us> <02770bea-b3f3-4!
 015-8a43-443ae345379c@vondra.me> <3579709.1775151816@sss.pgh.pa.us>!
  <63de1553-829a-488d-8ee0-976afb8dd32c@vondra.me>
Comments: In-reply-to Tomas Vondra <tomas@vondra.me>
	message dated "Thu, 02 Apr 2026 20:08:18 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3586482.1775155672.1@sss.pgh.pa.us>
Date: Thu, 02 Apr 2026 14:47:52 -0400
Message-ID: <3586483.1775155672@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3586483.1775155672%40sss.pgh.pa.us>
Precedence: bulk

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