Getting rid of intermittent PPC64 buildfarm failures

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Getting rid of intermittent PPC64 buildfarm failures
Дата
Msg-id 3479046.1602607848@sss.pgh.pa.us
обсуждение исходный текст
Список pgsql-hackers
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.com

diff --git a/src/test/regress/expected/errors.out b/src/test/regress/expected/errors.out
index 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 exceeded
diff --git a/src/test/regress/expected/infinite_recurse.out b/src/test/regress/expected/infinite_recurse.out
new file mode 100644
index 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 exceeded
diff --git a/src/test/regress/expected/infinite_recurse_1.out b/src/test/regress/expected/infinite_recurse_1.out
new file mode 100644
index 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
+\quit
diff --git a/src/test/regress/parallel_schedule b/src/test/regress/parallel_schedule
index 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_existsupdatable_views roleattributes create_am hash_func errors 
+test: create_aggregate create_function_3 create_cast constraints triggers select inherit typed_table vacuum
drop_if_existsupdatable_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_schedule
index 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.sql
index 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_MESSAGE
diff --git a/src/test/regress/sql/infinite_recurse.sql b/src/test/regress/sql/infinite_recurse.sql
new file mode 100644
index 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: lost replication slots after pg_upgrade
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: lost replication slots after pg_upgrade