Allow passing extra options to initdb for tests
I'm proposing here a way to pass extra options to initdb when run
internally during test setup in pg_regress or
PostgreSQL::Test::Cluster's init (which covers just about all test
suites other than initdb's own tests).
For example:
make check PG_TEST_INITDB_EXTRA_OPTS='-k -c work_mem=50MB'
We currently document at [0]https://www.postgresql.org/docs/devel/regress-run.html#REGRESS-RUN-CUSTOM-SETTINGS a way to pass custom server settings to the
tests via PGOPTIONS. But this only works for pg_regress and only for
options that can be changed at run time. My proposal can set initdb
options, and since initdb has the -c option now, it can set any GUC
parameter as well.
I think this can be useful for a wide variety of uses, like running all
tests with checksums enabled, or with JIT enabled, or with different GUC
settings, or with different locale settings. (The existing pg_regress
--no-locale option is essentially a special case of this, but it only
provides one particular locale setting, not things like changing the
default provider etc.)
Of course, not all tests are going to pass with arbitrary options, but
it is useful to run this against specific test suites.
This patch also updates the documentation at [0]https://www.postgresql.org/docs/devel/regress-run.html#REGRESS-RUN-CUSTOM-SETTINGS to explain the new
method and distinguish it from the previously documented methods.
[0]: https://www.postgresql.org/docs/devel/regress-run.html#REGRESS-RUN-CUSTOM-SETTINGS
https://www.postgresql.org/docs/devel/regress-run.html#REGRESS-RUN-CUSTOM-SETTINGS
Attachments:
v0-0001-Allow-passing-extra-options-to-initdb-for-tests.patchtext/plain; charset=UTF-8; name=v0-0001-Allow-passing-extra-options-to-initdb-for-tests.patchDownload
From f2dad8de9af12852ac022e7b43c2996b343aeb23 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Tue, 6 Feb 2024 10:44:55 +0100
Subject: [PATCH v0] Allow passing extra options to initdb for tests
Setting the environment variable PG_TEST_INITDB_EXTRA_OPTS passes
extra options to initdb run by pg_regress or
PostgreSQL::Test::Cluster's init.
---
doc/src/sgml/regress.sgml | 34 +++++++++++++++++++-----
src/test/perl/PostgreSQL/Test/Cluster.pm | 7 +++++
src/test/regress/pg_regress.c | 7 ++++-
3 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
index 70d9bdefe1b..6a27aae3195 100644
--- a/doc/src/sgml/regress.sgml
+++ b/doc/src/sgml/regress.sgml
@@ -390,12 +390,37 @@ <title>Locale and Encoding</title>
<title>Custom Server Settings</title>
<para>
- Custom server settings to use when running a regression test suite can be
+ There are several ways to use custom server settings when running a test
+ suite. This can be useful to enable additional logging, adjust resource
+ limits, or enable extra run-time checks such as <xref
+ linkend="guc-debug-discard-caches"/>. But note that not all tests can be
+ expected to pass cleanly with arbitrary settings.
+ </para>
+
+ <para>
+ Extra options can be passed to the various <command>initdb</command>
+ commands that are run internally during test setup using the environment
+ variable <envar>PG_TEST_INITDB_EXTRA_OPTS</envar>. For example, to run a
+ test with checksums enabled and a custom WAL segment size and
+ <varname>work_mem</varname> setting, use:
+<screen>
+make check PG_TEST_INITDB_EXTRA_OPTS='-k --wal-segsize=4 -c work_mem=50MB'
+</screen>
+ </para>
+
+ <para>
+ For the core regression test suite and other tests driven by
+ <command>pg_regress</command>, custom run-time server settings can also be
set in the <varname>PGOPTIONS</varname> environment variable (for settings
- that allow this):
+ that allow this), for example:
<screen>
make check PGOPTIONS="-c debug_parallel_query=regress -c work_mem=50MB"
</screen>
+ (This makes use of functionality provided by libpq; see <xref
+ linkend="libpq-connect-options"/> for details.)
+ </para>
+
+ <para>
When running against a temporary installation, custom settings can also be
set by supplying a pre-written <filename>postgresql.conf</filename>:
<screen>
@@ -405,11 +430,6 @@ <title>Custom Server Settings</title>
</screen>
</para>
- <para>
- This can be useful to enable additional logging, adjust resource limits,
- or enable extra run-time checks such as <xref
- linkend="guc-debug-discard-caches"/>.
- </para>
</sect2>
<sect2 id="regress-run-extra-tests">
diff --git a/src/test/perl/PostgreSQL/Test/Cluster.pm b/src/test/perl/PostgreSQL/Test/Cluster.pm
index e2e70d0dbf9..07da74cf562 100644
--- a/src/test/perl/PostgreSQL/Test/Cluster.pm
+++ b/src/test/perl/PostgreSQL/Test/Cluster.pm
@@ -114,6 +114,7 @@ use Socket;
use Test::More;
use PostgreSQL::Test::Utils ();
use PostgreSQL::Test::BackgroundPsql ();
+use Text::ParseWords qw(shellwords);
use Time::HiRes qw(usleep);
use Scalar::Util qw(blessed);
@@ -519,6 +520,12 @@ sub init
$params{allows_streaming} = 0 unless defined $params{allows_streaming};
$params{has_archiving} = 0 unless defined $params{has_archiving};
+ my $initdb_extra_opts_env = $ENV{PG_TEST_INITDB_EXTRA_OPTS};
+ if (defined $initdb_extra_opts_env)
+ {
+ push @{ $params{extra} }, shellwords($initdb_extra_opts_env);
+ }
+
mkdir $self->backup_dir;
mkdir $self->archive_dir;
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index c894005dac0..f1f6011ae0a 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -2306,6 +2306,7 @@ regression_main(int argc, char *argv[],
const char *keywords[4];
const char *values[4];
PGPing rv;
+ const char *initdb_extra_opts_env;
/*
* Prepare the temp instance
@@ -2327,6 +2328,8 @@ regression_main(int argc, char *argv[],
if (!directory_exists(buf))
make_directory(buf);
+ initdb_extra_opts_env = getenv("PG_TEST_INITDB_EXTRA_OPTS");
+
initStringInfo(&cmd);
/*
@@ -2339,7 +2342,7 @@ regression_main(int argc, char *argv[],
* duplicate it until we require perl at build time.
*/
initdb_template_dir = getenv("INITDB_TEMPLATE");
- if (initdb_template_dir == NULL || nolocale || debug)
+ if (initdb_template_dir == NULL || nolocale || debug || initdb_extra_opts_env)
{
note("initializing database system by running initdb");
@@ -2352,6 +2355,8 @@ regression_main(int argc, char *argv[],
appendStringInfoString(&cmd, " --debug");
if (nolocale)
appendStringInfoString(&cmd, " --no-locale");
+ if (initdb_extra_opts_env)
+ appendStringInfo(&cmd, " %s", initdb_extra_opts_env);
appendStringInfo(&cmd, " > \"%s/log/initdb.log\" 2>&1", outputdir);
fflush(NULL);
if (system(cmd.data))
base-commit: b83033c3cff556d520281aaec399e47b4f11edbe
--
2.43.0
2024年2月6日(火) 19:54 Peter Eisentraut <peter@eisentraut.org>:
I'm proposing here a way to pass extra options to initdb when run
internally during test setup in pg_regress or
PostgreSQL::Test::Cluster's init (which covers just about all test
suites other than initdb's own tests).For example:
make check PG_TEST_INITDB_EXTRA_OPTS='-k -c work_mem=50MB'
We currently document at [0] a way to pass custom server settings to the
tests via PGOPTIONS. But this only works for pg_regress and only for
options that can be changed at run time. My proposal can set initdb
options, and since initdb has the -c option now, it can set any GUC
parameter as well.I think this can be useful for a wide variety of uses, like running all
tests with checksums enabled, or with JIT enabled, or with different GUC
settings, or with different locale settings. (The existing pg_regress
--no-locale option is essentially a special case of this, but it only
provides one particular locale setting, not things like changing the
default provider etc.)Of course, not all tests are going to pass with arbitrary options, but
it is useful to run this against specific test suites.This patch also updates the documentation at [0] to explain the new
method and distinguish it from the previously documented methods.
+1 for this, I recently ran into an issue with the regression tests for an
extension where it would have been very useful to provide some initdb
options.
Patch works as expected after a quick initial test.
Regards
Ian Barwick
2024年2月7日(水) 12:51 Ian Lawrence Barwick <barwick@gmail.com>:
2024年2月6日(火) 19:54 Peter Eisentraut <peter@eisentraut.org>:
I'm proposing here a way to pass extra options to initdb when run
internally during test setup in pg_regress or
PostgreSQL::Test::Cluster's init (which covers just about all test
suites other than initdb's own tests).For example:
make check PG_TEST_INITDB_EXTRA_OPTS='-k -c work_mem=50MB'
We currently document at [0] a way to pass custom server settings to the
tests via PGOPTIONS. But this only works for pg_regress and only for
options that can be changed at run time. My proposal can set initdb
options, and since initdb has the -c option now, it can set any GUC
parameter as well.I think this can be useful for a wide variety of uses, like running all
tests with checksums enabled, or with JIT enabled, or with different GUC
settings, or with different locale settings. (The existing pg_regress
--no-locale option is essentially a special case of this, but it only
provides one particular locale setting, not things like changing the
default provider etc.)Of course, not all tests are going to pass with arbitrary options, but
it is useful to run this against specific test suites.This patch also updates the documentation at [0] to explain the new
method and distinguish it from the previously documented methods.+1 for this, I recently ran into an issue with the regression tests for an
extension where it would have been very useful to provide some initdb
options.Patch works as expected after a quick initial test.
I had a longer look at this and can't find any issues with the code or
documentation changes.
I did wonder whether it would be worth mentioning that any initdb
options set in "PG_TEST_INITDB_EXTRA_OPTS" will override those
which can be set by pg_regress, but of the four ("--no-clean", "--no-sync",
"--debug" and "--no-locale"), only the optional "--no-locale" can actually
be overridden, so it doesn't seem important.
Regards
Ian Barwick
On Tue, Feb 6, 2024 at 4:24 PM Peter Eisentraut <peter@eisentraut.org> wrote:
I think this can be useful for a wide variety of uses, like running all
tests with checksums enabled, or with JIT enabled, or with different GUC
settings, or with different locale settings. (The existing pg_regress
--no-locale option is essentially a special case of this, but it only
provides one particular locale setting, not things like changing the
default provider etc.)Of course, not all tests are going to pass with arbitrary options, but
it is useful to run this against specific test suites.
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
On 14.02.24 06:22, Ian Lawrence Barwick wrote:
I had a longer look at this and can't find any issues with the code or
documentation changes.
Thanks, committed.
I did wonder whether it would be worth mentioning that any initdb
options set in "PG_TEST_INITDB_EXTRA_OPTS" will override those
which can be set by pg_regress, but of the four ("--no-clean", "--no-sync",
"--debug" and "--no-locale"), only the optional "--no-locale" can actually
be overridden, so it doesn't seem important.
I thought about this. We don't have a man page for pg_regress, so there
is no place to comprehensively document all the options and their
interactions. The documentation in regress.sgml works on a makefile
level. AFAICT, the --debug option is not exposed via the makefiles at
all, while --no-locale can be requested by the environment variable
NOLOCALE, but that is not documented, and also not ported to meson. I
think if you want tweaks on this level, there is some expectations right
now that you might need to study the source code a bit.
One thing that might be interesting would be to allow running initdb
without the --no-sync option, to exercise fsync a bit. But there is no
"--yes-sync" option to override --no-sync, otherwise you could do it
with the just-committed feature.
On 15 Feb 2024, at 11:38, Peter Eisentraut <peter@eisentraut.org> wrote:
We don't have a man page for pg_regress, so there is no place to comprehensively document all the options and their interactions.
This comes up every now and again, just yesterday there was a question on
-general [0]CACX+KaPOzzRHEt4w_=iqKbTpMKjyrUGVng1C749yP3r6dprtcg@mail.gmail.com about alternate output files which also are undocumented. Maybe
it's time to add documentation for pg_regress?
--
Daniel Gustafsson
[0]: CACX+KaPOzzRHEt4w_=iqKbTpMKjyrUGVng1C749yP3r6dprtcg@mail.gmail.com
Daniel Gustafsson <daniel@yesql.se> writes:
On 15 Feb 2024, at 11:38, Peter Eisentraut <peter@eisentraut.org> wrote:
We don't have a man page for pg_regress, so there is no place to comprehensively document all the options and their interactions.
This comes up every now and again, just yesterday there was a question on
-general [0] about alternate output files which also are
undocumented.
Really?
https://www.postgresql.org/docs/devel/regress-variant.html
Maybe it's time to add documentation for pg_regress?
I'm inclined to think that a formal man page wouldn't be that useful,
since nobody ever invokes pg_regress directly; as Peter says, what
is of interest is the "make check" targets and the corresponding meson
behaviors. I think 32.1 is already reasonably thorough about the
make targets; but the complete lack of equivalent info about what
to do in a meson build clearly needs to be rectified.
regards, tom lane
On 15 Feb 2024, at 16:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
On 15 Feb 2024, at 11:38, Peter Eisentraut <peter@eisentraut.org> wrote:
We don't have a man page for pg_regress, so there is no place to comprehensively document all the options and their interactions.
This comes up every now and again, just yesterday there was a question on
-general [0] about alternate output files which also are
undocumented.Really?
Doh, I missed that when looking.
Maybe it's time to add documentation for pg_regress?
I'm inclined to think that a formal man page wouldn't be that useful,
since nobody ever invokes pg_regress directly;
Right, I was mostly thinking of a chapter along the lines of "I am an extension
author, what features does this tool have to help me write good tests".
the complete lack of equivalent info about what
to do in a meson build clearly needs to be rectified.
Indeed.
--
Daniel Gustafsson