Message-ID: <c3a2b730-9d90-4a66-ae5e-50f6d77922d6@vondra.me>
Date: Sun, 29 Mar 2026 15:33:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pg_waldump: support decoding of WAL inside tarfile
To: Tom Lane <tgl@sss.pgh.pa.us>
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>
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>
 <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>
Content-Language: en-US
From: Tomas Vondra <tomas@vondra.me>
In-Reply-To: <1630755.1774739531@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/c3a2b730-9d90-4a66-ae5e-50f6d77922d6%40vondra.me>
Precedence: bulk


On 3/29/26 00:12, Tom Lane wrote:
> Tomas Vondra <tomas@vondra.me> writes:
>> On 3/28/26 23:36, Tom Lane wrote:
>>> It's apparently been there and been default since FreeBSD 13.1.
>>> This leads one to wonder how come BF member dikkop is managing
>>> to run this test successfully.  I speculate that it's using a
>>> filesystem type that doesn't do sparse files (cc'ing Vondra
>>> for confirmation on that).
> 
>> It's running on ufs. But I think the explanation is very simple. We had
>> a short power outage on Thursday, and the FreeBSD machine failed to boot
>> properly after the power was restored. IIUC this test is new, right?
> 
> Not that new, it dates to b15c15139, about a week ago.
> 
> I've reproduced Thomas' failure on a local FreeBSD 15.0 image
> using zfs, and confirmed that this cowboy hack fixes it:
> 

Interesting. Then I guess it has to be due to some difference in ufs vs.
zfs, when handling sparse files. It might be useful to add a bit more
variation here, and switch some of the animals to non-default
filesystems (not just the FreeBSD ones, which we seem to have only two
that run reasonably often). I'd bet most of the linux systems run on
ext4/xfs, few on btrfs/zfs.

regards

-- 
Tomas Vondra