public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v1] meson: adjust test timeout for Valgrind builds 4+ messages / 2 participants [nested] [flat]
* [PATCH v1] meson: adjust test timeout for Valgrind builds @ 2026-04-03 10:17 Bertrand Drouvot <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Bertrand Drouvot @ 2026-04-03 10:17 UTC (permalink / raw) When building with -DUSE_VALGRIND, tests run significantly slower due to Valgrind's instrumentation overhead, causing the default 1000s timeout to be exceeded. This commit detects Valgrind builds using a compiler check, which correctly handles USE_VALGRIND being passed via -Dc_args, CPPFLAGS or CFLAGS and increases the test timeout to 10000s in that case. No changes are needed for autoconf as it has no test timeout mechanism. Author: Bertrand Drouvot <[email protected]> Discussion: https://postgr.es/m/ --- meson.build | 10 ++++++++-- src/test/isolation/meson.build | 8 +++++++- src/test/regress/meson.build | 7 ++++++- 3 files changed, 21 insertions(+), 4 deletions(-) 29.3% src/test/isolation/ 29.2% src/test/regress/ diff --git a/meson.build b/meson.build index 6bc74c2ba79..7d376495e20 100644 --- a/meson.build +++ b/meson.build @@ -3888,6 +3888,12 @@ install_suites = [] testwrap = files('src/tools/testwrap') +# Detect if built with Valgrind support to adjust test timeouts +is_valgrind_build = cc.compiles(''' +#ifndef USE_VALGRIND +choke me +#endif''', name: 'USE_VALGRIND check', args: test_c_args) + foreach test_dir : tests testwrap_base = [ testwrap, @@ -3955,7 +3961,7 @@ foreach test_dir : tests test_kwargs = { 'protocol': 'tap', 'priority': 10, - 'timeout': 1000, + 'timeout': is_valgrind_build ? 10000 : 1000, 'depends': test_deps + t.get('deps', []), 'env': env, } + t.get('test_kwargs', {}) @@ -4028,7 +4034,7 @@ foreach test_dir : tests test_kwargs = { 'protocol': 'tap', 'suite': test_group, - 'timeout': 1000, + 'timeout': is_valgrind_build ? 10000 : 1000, 'depends': test_deps + t.get('deps', []), 'env': env, } + t.get('test_kwargs', {}) diff --git a/src/test/isolation/meson.build b/src/test/isolation/meson.build index c55b8d71848..87786dacf81 100644 --- a/src/test/isolation/meson.build +++ b/src/test/isolation/meson.build @@ -59,6 +59,12 @@ isolationtester = executable('isolationtester', ) bin_targets += isolationtester +# Detect if built with Valgrind support to adjust test timeouts +is_valgrind_build = cc.compiles(''' +#ifndef USE_VALGRIND +choke me +#endif''', name: 'USE_VALGRIND check') + tests += { 'name': 'isolation', 'sd': meson.current_source_dir(), @@ -67,7 +73,7 @@ tests += { 'schedule': files('isolation_schedule'), 'test_kwargs': { 'priority': 40, - 'timeout': 1000, + 'timeout': is_valgrind_build ? 10000 : 1000, }, 'dbname': 'isolation_regression', }, diff --git a/src/test/regress/meson.build b/src/test/regress/meson.build index a5f2222e83a..196cf263c6d 100644 --- a/src/test/regress/meson.build +++ b/src/test/regress/meson.build @@ -43,6 +43,11 @@ regress_module = shared_module('regress', ) test_install_libs += regress_module +# Detect if built with Valgrind support to adjust test timeouts +is_valgrind_build = cc.compiles(''' +#ifndef USE_VALGRIND +choke me +#endif''', name: 'USE_VALGRIND check') tests += { 'name': 'regress', @@ -52,7 +57,7 @@ tests += { 'schedule': files('parallel_schedule'), 'test_kwargs': { 'priority': 50, - 'timeout': 1000, + 'timeout': is_valgrind_build ? 10000 : 1000, }, 'dbname': 'regression', }, -- 2.34.1 --9mXTMSOWn9DVpXyR-- ^ permalink raw reply [nested|flat] 4+ messages in thread
* meson: Adjust test timeout for Valgrind builds @ 2026-04-03 14:53 Bertrand Drouvot <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Bertrand Drouvot @ 2026-04-03 14:53 UTC (permalink / raw) To: [email protected] Hi hackers, When building with -DUSE_VALGRIND, tests run significantly slower due to Valgrind's instrumentation overhead, causing the default 1000s test's timeout to be exceeded. Example when running the regress test suite: " $ meson test -C build -q --print-errorlogs --setup running --suite regress-running regress-running - postgresql:regress-running/regress time out (After 1000 seconds) Summary of Failures: 1/1 regress-running - postgresql:regress-running/regress TIMEOUT 1000.01s Ok: 0 Fail: 0 Timeout: 1 " PFA a patch that detects Valgrind builds using a compiler check, which correctly handles USE_VALGRIND being passed via -Dc_args, CPPFLAGS or CFLAGS and increases the test timeout to 10000s in that case. I don't have a strong opinion on the new value. In practice, the regress suite runs in about 30 seconds without Valgrind and in about 46 minutes with Valgrind on my setup. Note that the timeout is per test, not for the entire suite so that 10000s looks large enough (I tested to run the entire suite with the patch and it did not produce any timeout). Another option could be to disable the timeout on a Valgrind build (set timeout to 0) but then a test could block forever. Note that there are no changes needed for autoconf as it does not set a timeout for the tests. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: meson: Adjust test timeout for Valgrind builds @ 2026-04-06 13:25 Andres Freund <[email protected]> parent: Bertrand Drouvot <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Andres Freund @ 2026-04-06 13:25 UTC (permalink / raw) To: Bertrand Drouvot <[email protected]>; +Cc: [email protected] Hi, On 2026-04-03 14:53:15 +0000, Bertrand Drouvot wrote: > When building with -DUSE_VALGRIND, tests run significantly slower due > to Valgrind's instrumentation overhead, causing the default 1000s test's timeout > to be exceeded. Example when running the regress test suite: > > " > $ meson test -C build -q --print-errorlogs --setup running --suite regress-running > regress-running - postgresql:regress-running/regress time out (After 1000 seconds) > > Summary of Failures: > > 1/1 regress-running - postgresql:regress-running/regress TIMEOUT 1000.01s > > Ok: 0 > Fail: 0 > Timeout: 1 > " > > PFA a patch that detects Valgrind builds using a compiler check, which correctly > handles USE_VALGRIND being passed via -Dc_args, CPPFLAGS or CFLAGS and increases > the test timeout to 10000s in that case. > > I don't have a strong opinion on the new value. In practice, the regress > suite runs in about 30 seconds without Valgrind and in about 46 minutes with > Valgrind on my setup. Note that the timeout is per test, not for the entire > suite so that 10000s looks large enough (I tested to run the entire suite with > the patch and it did not produce any timeout). > > Another option could be to disable the timeout on a Valgrind build (set timeout > to 0) but then a test could block forever. > > Note that there are no changes needed for autoconf as it does not set a timeout > for the tests. The usual way to deal with that is to pass --timeout-multiplier=100 or something like that to meson test. Greetings, Andres ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: meson: Adjust test timeout for Valgrind builds @ 2026-04-07 06:06 Bertrand Drouvot <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Bertrand Drouvot @ 2026-04-07 06:06 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: [email protected] Hi, On Mon, Apr 06, 2026 at 09:25:46AM -0400, Andres Freund wrote: > Hi, > > On 2026-04-03 14:53:15 +0000, Bertrand Drouvot wrote: > > When building with -DUSE_VALGRIND, tests run significantly slower due > > to Valgrind's instrumentation overhead, causing the default 1000s test's timeout > > to be exceeded. Example when running the regress test suite: > > > > " > > $ meson test -C build -q --print-errorlogs --setup running --suite regress-running > > regress-running - postgresql:regress-running/regress time out (After 1000 seconds) > > > > Summary of Failures: > > > > 1/1 regress-running - postgresql:regress-running/regress TIMEOUT 1000.01s > > > > Ok: 0 > > Fail: 0 > > Timeout: 1 > > " > > > > PFA a patch that detects Valgrind builds using a compiler check, which correctly > > handles USE_VALGRIND being passed via -Dc_args, CPPFLAGS or CFLAGS and increases > > the test timeout to 10000s in that case. > > > > I don't have a strong opinion on the new value. In practice, the regress > > suite runs in about 30 seconds without Valgrind and in about 46 minutes with > > Valgrind on my setup. Note that the timeout is per test, not for the entire > > suite so that 10000s looks large enough (I tested to run the entire suite with > > the patch and it did not produce any timeout). > > > > Another option could be to disable the timeout on a Valgrind build (set timeout > > to 0) but then a test could block forever. > > > > Note that there are no changes needed for autoconf as it does not set a timeout > > for the tests. > > The usual way to deal with that is to pass --timeout-multiplier=100 or > something like that to meson test. Yeah, that's another option but I see it as an extra step if the patched version still time out. Currently we know for sure that some tests will time out so I thought that was more use friendly to try to prevent that in the first place and use the multiplier if it's still not enough for any reasons. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-04-07 06:06 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-04-03 10:17 [PATCH v1] meson: adjust test timeout for Valgrind builds Bertrand Drouvot <[email protected]> 2026-04-03 14:53 meson: Adjust test timeout for Valgrind builds Bertrand Drouvot <[email protected]> 2026-04-06 13:25 ` Re: meson: Adjust test timeout for Valgrind builds Andres Freund <[email protected]> 2026-04-07 06:06 ` Re: meson: Adjust test timeout for Valgrind builds Bertrand Drouvot <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox