From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Cc: Mark Wong <mark@2ndquadrant.com>
Subject: Getting rid of intermittent PPC64 buildfarm failures
Date: Tue, 13 Oct 2020 12:50:48 -0400
Message-ID: <3479046.1602607848@sss.pgh.pa.us> (raw)
I grow quite weary of the number of buildfarm failures we see as a
consequence of the Linux PPC64 bug discussed in [1]. Although we can
anticipate that the fix will roll out into new kernel builds before much
longer, that will have very little effect on the buildfarm situation,
given that a lot of Mark's PPC64 armada is running hoary "stable" kernels.
It might be many years before there are no unpatched systems to worry about.
I think it's time to give up and disable the infinite_recurse test on such
platforms. It's teaching us nothing and we waste valuable developer time
eyeballing failures to make sure they're just the same old same old.
Testing the case on not-Linux-PPC64 is enough to verify that our own code
works.
We can use the same technique used in collate.linux.utf8.sql,
namely check the output of version() and abandon the test if it matches.
To minimize the maintenance pain from needing two expected-files, it seems
prudent to split infinite_recurse into its own test script, which leads
to the attached proposed patch.
Any objections?
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/20190723162703.GM22387%40telsasoft.comAttachments:disable-infinite-recurse-on-linux-ppc64.patch (text/x-diff, 6.1K) downloaddiff --git a/src/test/regress/expected/errors.out b/src/test/regress/expected/errors.outindex a525aa2f93..1e7b5a7046 100644--- a/src/test/regress/expected/errors.out+++ b/src/test/regress/expected/errors.out@@ -440,13 +440,3 @@ NULL);
ERROR: syntax error at or near "NUL"
LINE 16: ...L, id2 TEXT NOT NULL PRIMARY KEY, id3 INTEGER NOT NUL, id4 I...
^
--- Check that stack depth detection mechanism works and--- max_stack_depth is not set too high. The full error report is not--- very stable, so show only SQLSTATE and primary error message.-create function infinite_recurse() returns int as-'select infinite_recurse()' language sql;-\set VERBOSITY sqlstate-select infinite_recurse();-ERROR: 54001-\echo :LAST_ERROR_MESSAGE-stack depth limit exceededdiff --git a/src/test/regress/expected/infinite_recurse.out b/src/test/regress/expected/infinite_recurse.outnew file mode 100644index 0000000000..90f9631b24--- /dev/null+++ b/src/test/regress/expected/infinite_recurse.out@@ -0,0 +1,24 @@+-- Check that stack depth detection mechanism works and+-- max_stack_depth is not set too high.+create function infinite_recurse() returns int as+'select infinite_recurse()' language sql;+-- Unfortunately, up till mid 2020 the Linux kernel had a bug in PPC64+-- signal handling that would cause this test to crash if it happened+-- to receive an sinval catchup interrupt while the stack is deep:+-- https://bugzilla.kernel.org/show_bug.cgi?id=205183+-- It is likely to be many years before that bug disappears from all+-- production kernels, so disable this test on such platforms.+-- (We still create the function, so as not to have a cross-platform+-- difference in the end state of the regression database.)+SELECT version() ~ 'powerpc64.*-linux-gnu'+ AS skip_test \gset+\if :skip_test+\quit+\endif+-- The full error report is not very stable, so we show only SQLSTATE+-- and primary error message.+\set VERBOSITY sqlstate+select infinite_recurse();+ERROR: 54001+\echo :LAST_ERROR_MESSAGE+stack depth limit exceededdiff --git a/src/test/regress/expected/infinite_recurse_1.out b/src/test/regress/expected/infinite_recurse_1.outnew file mode 100644index 0000000000..ef2c8d66a7--- /dev/null+++ b/src/test/regress/expected/infinite_recurse_1.out@@ -0,0 +1,16 @@+-- Check that stack depth detection mechanism works and+-- max_stack_depth is not set too high.+create function infinite_recurse() returns int as+'select infinite_recurse()' language sql;+-- Unfortunately, up till mid 2020 the Linux kernel had a bug in PPC64+-- signal handling that would cause this test to crash if it happened+-- to receive an sinval catchup interrupt while the stack is deep:+-- https://bugzilla.kernel.org/show_bug.cgi?id=205183+-- It is likely to be many years before that bug disappears from all+-- production kernels, so disable this test on such platforms.+-- (We still create the function, so as not to have a cross-platform+-- difference in the end state of the regression database.)+SELECT version() ~ 'powerpc64.*-linux-gnu'+ AS skip_test \gset+\if :skip_test+\quitdiff --git a/src/test/regress/parallel_schedule b/src/test/regress/parallel_scheduleindex 026ea880cd..ae89ed7f0b 100644--- a/src/test/regress/parallel_schedule+++ b/src/test/regress/parallel_schedule@@ -55,7 +55,7 @@ test: create_index create_index_spgist create_view index_including index_includi
# ----------
# Another group of parallel tests
# ----------
-test: create_aggregate create_function_3 create_cast constraints triggers select inherit typed_table vacuum drop_if_exists updatable_views roleattributes create_am hash_func errors+test: create_aggregate create_function_3 create_cast constraints triggers select inherit typed_table vacuum drop_if_exists updatable_views roleattributes create_am hash_func errors infinite_recurse
# ----------
# sanity_check does a vacuum, affecting the sort order of SELECT *
diff --git a/src/test/regress/serial_schedule b/src/test/regress/serial_scheduleindex 979d926119..525bdc804f 100644--- a/src/test/regress/serial_schedule+++ b/src/test/regress/serial_schedule@@ -83,6 +83,7 @@ test: roleattributes
test: create_am
test: hash_func
test: errors
+test: infinite_recurse
test: sanity_check
test: select_into
test: select_distinct
diff --git a/src/test/regress/sql/errors.sql b/src/test/regress/sql/errors.sqlindex 86b672538a..66a56b28f6 100644--- a/src/test/regress/sql/errors.sql+++ b/src/test/regress/sql/errors.sql@@ -364,12 +364,3 @@ INT4
UNIQUE
NOT
NULL);
---- Check that stack depth detection mechanism works and--- max_stack_depth is not set too high. The full error report is not--- very stable, so show only SQLSTATE and primary error message.-create function infinite_recurse() returns int as-'select infinite_recurse()' language sql;-\set VERBOSITY sqlstate-select infinite_recurse();-\echo :LAST_ERROR_MESSAGEdiff --git a/src/test/regress/sql/infinite_recurse.sql b/src/test/regress/sql/infinite_recurse.sqlnew file mode 100644index 0000000000..ff4bf966f9--- /dev/null+++ b/src/test/regress/sql/infinite_recurse.sql@@ -0,0 +1,29 @@+-- Check that stack depth detection mechanism works and+-- max_stack_depth is not set too high.++create function infinite_recurse() returns int as+'select infinite_recurse()' language sql;++-- Unfortunately, up till mid 2020 the Linux kernel had a bug in PPC64+-- signal handling that would cause this test to crash if it happened+-- to receive an sinval catchup interrupt while the stack is deep:+-- https://bugzilla.kernel.org/show_bug.cgi?id=205183+-- It is likely to be many years before that bug disappears from all+-- production kernels, so disable this test on such platforms.+-- (We still create the function, so as not to have a cross-platform+-- difference in the end state of the regression database.)++SELECT version() ~ 'powerpc64.*-linux-gnu'+ AS skip_test \gset+\if :skip_test+\quit+\endif++-- The full error report is not very stable, so we show only SQLSTATE+-- and primary error message.++\set VERBOSITY sqlstate++select infinite_recurse();++\echo :LAST_ERROR_MESSAGE
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org, mark@2ndquadrant.com
Subject: Re: Getting rid of intermittent PPC64 buildfarm failures
In-Reply-To: <3479046.1602607848@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox