MIME-Version: 1.0
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> <3118179.1775092964@sss.pgh.pa.us>
 <CA+hUKG+-pn14s_tjEBO6YKHmc=uRhGVn=w2oM91KKnEUc7pH0Q@mail.gmail.com>
 <3565835.1775147392@sss.pgh.pa.us> <3579709.1775151816@sss.pgh.pa.us>
 <63de1553-829a-488d-8ee0-976afb8dd32c@vondra.me>
 <3586483.1775155672@sss.pgh.pa.us>
 <CAN55FZ026+y8nJYR5w8miiaQ4Mw8F1xtBdTdR52cDZ4fn2pQ8g@mail.gmail.com>
 <CA+hUKG+LekzSbmxbG4u5wDxQ9jHnzxN-wfdZ1pQSZquELmGtVA@mail.gmail.com>
 <CAA5RZ0tXWJdL5mTJ8p9RrnThPoja-2LDykUykcbJt5iSjmWe6Q@mail.gmail.com>
 <CAN55FZ1wLmdyMs4sABEad2MCKDtbK++F_ztjhkgEtaw+LahycA@mail.gmail.com>
 <CA+hUKGJ4JcGNWV0KHD5iChGhJ5Z1F8RXSdxnt2yOoW+KHJuLaQ@mail.gmail.com>
In-Reply-To: 
 <CA+hUKGJ4JcGNWV0KHD5iChGhJ5Z1F8RXSdxnt2yOoW+KHJuLaQ@mail.gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Fri, 10 Apr 2026 19:57:56 +1200
Message-ID: 
 <CA+hUKGJkeTVuq5u5WKJm6xkwmW577UuQ7fA=PyBCSR3h9g2GtQ@mail.gmail.com>
Subject: Re: pg_waldump: support decoding of WAL inside tarfile
To: Nazir Bilal Yavuz <byavuz81@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Tomas Vondra <tomas@vondra.me>, 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"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BhUKGJkeTVuq5u5WKJm6xkwmW577UuQ7fA%3DPyBCSR3h9g2GtQ%40mail.gmail.com>
Precedence: bulk

Nitpicking code review for commit b15c1513:

+read_archive_wal_page(XLogDumpPrivate *privateInfo, XLogRecPtr targetPagePtr,
+                     Size count, char *readBuff)

I thought we agreed to stop using Size for new code?  size_t has been
around since C89.

+               pg_fatal("WAL segment \"%s\" in archive \"%s\" is too short: rea
d %lld of %lld bytes",
+                        fname, privateInfo->archive_name,
+                        (long long int) (count - nbytes),
+                        (long long int) count);

Why cast to long long int?  That's the sort of thing we used to have
to do for int64 (but no longer), but here it's size_t anyway.  %zu has
been around since C99.