Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w6ccH-004TsA-2D for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Mar 2026 22:58:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w6cbF-00FJlQ-2m for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Mar 2026 22:57:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w6cbF-00FJlH-1Q for pgsql-hackers@lists.postgresql.org; Sat, 28 Mar 2026 22:57:49 +0000 Received: from relay7-d.mail.gandi.net ([217.70.183.200]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w6cbC-00000001iyu-1pme for pgsql-hackers@lists.postgresql.org; Sat, 28 Mar 2026 22:57:49 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id C480E3E95D; Sat, 28 Mar 2026 22:57:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vondra.me; s=gm1; t=1774738664; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bJ4mpSeGSoUhy0Y68LYyl6U/tYf3W0GyXKkDQmL3PEc=; b=UlHBPhWIWxxXtzt7WIqyGYryxz/ajUYUlIXCPG/+71PKdA+UHtIcEXpRPSqyczY/N1/Zbu IM0wF0QY/7T1C5xjEn4O4O+NmCcV9sWwFAkl2boj4xBkuvmmFWrjRMlLECOfAdnY+Fi4Y+ 8zyLzz9rNUyImsxCWhVWpQAcUXH4T4T5JW7cZ5m3S79tMuOSfQNskYEJSZ7xxSFeEXf07Q tqrmUu4goch5aATay5NMinEFAuMj092ELO8i6m9ECSr775poRJtor7vfRPsr273kpN35Hu 71Wgoa3mQDPxkoYVCwUjEu6WdhRBKlSZpQ8MaM12UpCFCvS7eGEHzdCQrme2Ew== Message-ID: <97a382c0-1f19-4ea0-951f-e37e6abc34a3@vondra.me> Date: Sat, 28 Mar 2026 23:57:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: pg_waldump: support decoding of WAL inside tarfile To: Tom Lane , Thomas Munro Cc: Andres Freund , Michael Paquier , Andrew Dunstan , Amul Sul , Zsolt Parragi , Robert Haas , Chao Li , Anthonin Bonnefoy , Fujii Masao , Jakub Wartak , PostgreSQL Hackers References: <2250061.1774104346@sss.pgh.pa.us> <2555285.1774131847@sss.pgh.pa.us> <2609460.1774153487@sss.pgh.pa.us> <2790913.1774200584@sss.pgh.pa.us> <2880042.1774203473@sss.pgh!!.pa.us> <3341199.1774221191@sss.pgh.pa.us> <3424809.1774234940@sss.pgh.pa.us> <1624716.1774736283@sss.pgh.pa.us> <1626907.1774737417@sss.pgh.pa.us> Content-Language: en-US From: Tomas Vondra In-Reply-To: <1626907.1774737417@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-GND-Sasl: tomas@vondra.me X-GND-Score: -100 X-GND-Cause: dmFkZTFOPMwFuzDoxynDfaV6hsQ3EbE4f2mme5hpVCy8AS63hQgO2qX1+gd8jvIPUqhkB7cBw9JpdkynzKqgdGwelgZo78vcXgpfsSJA+G39qlI3VAObiM68mLuH8HtAmhfjVZoMuW5eOJn7ROt73Y/ehRWscTX3RlTJEvczGSHiwbg3b6sr5ICXxf3kQ/Tz7SCAgrQopwrHRTJnlXFrJa1A2nS4o5qYeB7wK+lgLCRwZUXAsBoRUldRB+UUAxb5UzZF3AF1J0tcW5djk5maAz4kHtIMORpLoPA/UEeVACGtsnrjU9bbJrxghSXHywjdpC9CH9+DBPhx++mvSDFl37dEZ8NeOgKHOZQdpPa+KQ2C7yPlr6qLoqA68xa9jt/bIUkuk5wgmJaL7Jq03ZmCrOeelFNZdx2kopyGViZ9M79J5kNZhxbyGPcprMhvf9qgRr5SlfdZgFXYPou4mkiATIlqR5WVezQGeegutjsx/qAQtvtwHthIQe9gcrMNAG8KOCNwZICIdfqXZuW3a3a7p0JIVQyqbGhqwNOI2PkmBfGevjBzwb76GOu24njBfJ1kAG5lkSuoL4UFumn+cMr3n7T5JGXNrSuFVmqK+fOLWazBJacbMiQGyxVmpZXqQ9f1lYY3VUx8oEQcyyPi9wks+6Eo/hU8MLmIfN/dnd8SnGqOtYwbdg X-GND-State: clean List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 3/28/26 23:36, Tom Lane wrote: > I wrote: >> However ... I do not find any indication in the GNU tar docs >> that it produces sparse files by default. It looks like you >> need to say -S/--sparse to make that happen. Maybe you have >> a version that's been hacked to make that the default? > > Bleah. Digging in the man pages at freebsd.org, I read > > --read-sparse > (c, r, u modes only) Read sparse file information from disk. > This is the reverse of --no-read-sparse and the default behav- > ior. > > 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? I fixed the machine, it'll start running the tests in a couple minutes. regards -- Tomas Vondra