]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Further harden tests that might use not-so-compatible tar versions.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 2 Apr 2026 21:21:18 +0000 (17:21 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 2 Apr 2026 21:21:27 +0000 (17:21 -0400)
commitebba64c08d965550b2d034ee931a27fdf2de56b7
treeb41a3169b2d5812a107def88e608334e6118d732
parentbd4f879a9cdd11b6b683cea0ea51d7c27a8f1153
Further harden tests that might use not-so-compatible tar versions.

Buildfarm testing shows that OpenSUSE (and perhaps related platforms?)
configures GNU tar in such a way that it'll archive sparse WAL files
by default, thus triggering the pax-extension detection code added by
bc30c704a.  Thus, we need something similar to 852de579a but for
GNU tar's option set.  "--format=ustar" seems to do the trick.

Moreover, the buildfarm shows that pg_verifybackup's 003_corruption.pl
test script is also triggering creation of pax-format tar files on
that platform.  We had not noticed because those test cases all fail
(intentionally) before getting to the point of trying to verify WAL
data.

Since that means two TAP scripts need this option-selection logic, and
plausibly more will do so in future, factor it out into a subroutine
in Test::Utils.  We also need to back-patch the 003_corruption.pl fix
into v18, where it's also failing.

While at it, clean up some places where guards for $tar being empty
or undefined were incomplete or even outright backwards.  Presumably,
we missed noticing because the set of machines that run TAP tests
and don't have tar installed is empty.  But if we're going to try
to handle that scenario, we should do it correctly.

Reported-by: Tomas Vondra <tomas@vondra.me>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/02770bea-b3f3-4015-8a43-443ae345379c@vondra.me
Backpatch-through: 18
src/bin/pg_verifybackup/t/003_corruption.pl
src/bin/pg_waldump/t/001_basic.pl
src/test/perl/PostgreSQL/Test/Utils.pm