MIME-Version: 1.0
References: <2250061.1774104346@sss.pgh.pa.us>
 <2555285.1774131847@sss.pgh.pa.us>
 <2609460.1774153487@sss.pgh.pa.us>
 <CAD5tBcLVWKnph3iB-VPuPKR0dCckOJRFZW2-4H7HTTmhw8-vOg@mail.gmail.com>
 <2790913.1774200584@sss.pgh.pa.us> <2880042.1774203473@sss.pgh!!.pa.us>
 <CAD5tBcLsYDz+Nzx8MryjxiKaN3fGKd4ZgXuN1Jn=CYxw9dh+AA@mail.gmail.com>
 <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>
 <1621589.1774734569@sss.pgh.pa.us>
In-Reply-To: <1621589.1774734569@sss.pgh.pa.us>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Sun, 29 Mar 2026 11:08:43 +1300
Message-ID: 
 <CA+hUKGKjRa0NmHCUc2XaF=FjdSztm357VgtUhH4LXhCmisLfaA@mail.gmail.com>
Subject: Re: pg_waldump: support decoding of WAL inside tarfile
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BhUKGKjRa0NmHCUc2XaF%3DFjdSztm357VgtUhH4LXhCmisLfaA%40mail.gmail.com>
Precedence: bulk

On Sun, Mar 29, 2026 at 10:49=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote=
:
> Huh.  What is your platform exactly?  Maybe more to the point,
> what is the tar program you're using?

FreeBSD tar 3.8.2.

> > Seems like it already stepped over 000000010000000000000002 earlier?
> > Could it be a table-of-contents order dependency bug or something like
> > that?
>
> If you look at the TAP script, you'll see that it tries to randomize
> the order of the entries in the tar file (see sub generate_archive).
> So if that's the problem, it shouldn't reproduce 100%, and also we
> should be seeing lots of freckles on the buildfarm.  We're not, so
> there must be something off-the-beaten-track about your test
> environment.

Right, I see now.  There is something different about
000000010000000000000002 though: it doesn't seem to have a normal
(non-PAX, non-GNU) TOC entry, unlike000000010000000000000001.  Trying
to figure out why...