On sparc64+ext4, suppress test failures from known WAL read failure.
authorNoah Misch <[email protected]>
Thu, 27 Jan 2022 02:06:19 +0000 (18:06 -0800)
committerNoah Misch <[email protected]>
Thu, 27 Jan 2022 02:06:23 +0000 (18:06 -0800)
Buildfarm members kittiwake, tadarida and snapper began to fail
frequently when commits 3cd9c3b921977272e6650a5efbeade4203c4bca2 and
f47ed79cc8a0cfa154dc7f01faaf59822552363f added tests of concurrency, but
the problem was reachable before those commits.  Back-patch to v10 (all
supported versions).

Discussion: https://postgr.es/m/20220116210241[email protected]

src/bin/pgbench/t/023_cic_2pc.pl
src/test/perl/TestLib.pm

index e29c2564b77841f8d52b9df7d6d8f2213d05927a..707f28c34e85090950391c9a8648102884ad16fc 100644 (file)
@@ -11,6 +11,8 @@ use TestLib;
 
 use Test::More tests => 6;
 
+local $TODO = 'filesystem bug' if TestLib::has_wal_read_bug;
+
 my ($node, $result);
 
 #
index 2676976ed03514733efd421a83c2e5ea77a1d6b2..3359b18420395d9a841bc247ec5ad4c3583e3ba7 100644 (file)
@@ -211,6 +211,29 @@ sub perl2host
    return $dir . $leaf;
 }
 
+=pod
+
+=item has_wal_read_bug()
+
+Returns true if $tmp_check is subject to a sparc64+ext4 bug that causes WAL
+readers to see zeros if another process simultaneously wrote the same offsets.
+Consult this in tests that fail frequently on affected configurations.  The
+bug has made streaming standbys fail to advance, reporting corrupt WAL.  It
+has made COMMIT PREPARED fail with "could not read two-phase state from WAL".
+Non-WAL PostgreSQL reads haven't been affected, likely because those readers
+and writers have buffering systems in common.  See
+https://postgr.es/m/[email protected] for details.
+
+=cut
+
+sub has_wal_read_bug
+{
+   return
+        $Config{osname} eq 'linux'
+     && $Config{archname} =~ /^sparc/
+     && !run_log([ qw(df -x ext4), $tmp_check ], '>', '/dev/null', '2>&1');
+}
+
 sub system_log
 {
    print("# Running: " . join(" ", @_) . "\n");