pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedinitdb caching during tests
15+ messages / 6 participants
[nested] [flat]
* initdb caching during tests
@ 2023-08-05 19:56 Andres Freund <andres@anarazel.de>
2023-08-05 20:58 ` Re: initdb caching during tests Tom Lane <tgl@sss.pgh.pa.us>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
0 siblings, 2 replies; 15+ messages in thread
From: Andres Freund @ 2023-08-05 19:56 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; +Cc: Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
Hi,
We have some issues with CI on macos and windows being too expensive (more on
that soon in a separate email), which reminded me of this thread (with
original title: [1])
I've attached a somewhat cleaned up version of the patch to cache initdb
across runs. The results are still fairly impressive in my opinion.
One thing I do not like, but don't have a good idea for how to improve, is
that there's a bunch of duplicated logic in pg_regress.c and Cluster.pm. I've
tried to move that into initdb.c itself, but that ends up pretty ugly, because
we need to be a lot more careful about checking whether options are compatible
etc. I've also thought about just putting this into a separate perl script,
but right now we still allow basic regression tests without perl being
available. So I concluded that for now just having the copies is the best
answer.
Times for running all tests under meson, on my workstation (20 cores / 40
threads):
cassert build -O2:
Before:
real 0m44.638s
user 7m58.780s
sys 2m48.773s
After:
real 0m38.938s
user 2m37.615s
sys 2m0.570s
cassert build -O0:
Before:
real 1m11.290s
user 13m9.817s
sys 2m54.946s
After:
real 1m2.959s
user 3m5.835s
sys 1m59.887s
non-cassert build:
Before:
real 0m34.579s
user 5m30.418s
sys 2m40.507s
After:
real 0m27.710s
user 2m20.644s
sys 1m55.770s
On CI this reduces the test times substantially:
Freebsd 8:51 -> 5:35
Debian w/ asan, autoconf 6:43 -> 4:55
Debian w/ alignmentsan, ubsan 4:02 -> 2:33
macos 5:07 -> 4:29
windows 10:21 -> 9:49
This is ignoring a bit of run-to-run variance, but the trend is obvious enough
that it's not worth worrying about that.
Greetings,
Andres Freund
[1] https://postgr.es/m/20220120021859.3zpsfqn4z7ob7afz%40alap3.anarazel.de
Attachments:
[text/x-diff] v3-0001-Use-template-initdb-in-tests.patch (10.4K, ../../20230805195656.wouaaf6qvrdo2cjt@awork3.anarazel.de/2-v3-0001-Use-template-initdb-in-tests.patch)
download | inline diff:
From 0fd431c277f01284a91999a04368de6b59b6691e Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Thu, 2 Feb 2023 21:51:53 -0800
Subject: [PATCH v3 1/2] Use "template" initdb in tests
Discussion: https://postgr.es/m/20220120021859.3zpsfqn4z7ob7afz@alap3.anarazel.de
---
meson.build | 30 ++++++++++
.cirrus.yml | 3 +-
src/test/perl/PostgreSQL/Test/Cluster.pm | 46 ++++++++++++++-
src/test/regress/pg_regress.c | 74 ++++++++++++++++++------
src/Makefile.global.in | 52 +++++++++--------
5 files changed, 161 insertions(+), 44 deletions(-)
diff --git a/meson.build b/meson.build
index 04ea3488522..47429a18c3f 100644
--- a/meson.build
+++ b/meson.build
@@ -3056,8 +3056,10 @@ testport = 40000
test_env = environment()
temp_install_bindir = test_install_location / get_option('bindir')
+test_initdb_template = meson.build_root() / 'tmp_install' / 'initdb-template'
test_env.set('PG_REGRESS', pg_regress.full_path())
test_env.set('REGRESS_SHLIB', regress_module.full_path())
+test_env.set('INITDB_TEMPLATE', test_initdb_template)
# Test suites that are not safe by default but can be run if selected
# by the user via the whitespace-separated list in variable PG_TEST_EXTRA.
@@ -3072,6 +3074,34 @@ if library_path_var != ''
endif
+# Create (and remove old) initdb template directory. Tests use that, where
+# possible, to make it cheaper to run tests.
+#
+# Use python to remove the old cached initdb, as we cannot rely on a working
+# 'rm' binary on windows.
+test('initdb_cache',
+ python,
+ args: [
+ '-c', '''
+import shutil
+import sys
+import subprocess
+
+shutil.rmtree(sys.argv[1], ignore_errors=True)
+sp = subprocess.run(sys.argv[2:] + [sys.argv[1]])
+sys.exit(sp.returncode)
+''',
+ test_initdb_template,
+ temp_install_bindir / 'initdb',
+ '-A', 'trust', '-N', '--no-instructions'
+ ],
+ priority: setup_tests_priority - 1,
+ timeout: 300,
+ is_parallel: false,
+ env: test_env,
+ suite: ['setup'])
+
+
###############################################################
# Test Generation
diff --git a/.cirrus.yml b/.cirrus.yml
index d260f15c4e2..8fce17dff08 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -115,8 +115,9 @@ task:
test_minimal_script: |
su postgres <<-EOF
ulimit -c unlimited
+ meson test $MTEST_ARGS --suite setup
meson test $MTEST_ARGS --num-processes ${TEST_JOBS} \
- tmp_install cube/regress pg_ctl/001_start_stop
+ cube/regress pg_ctl/001_start_stop
EOF
on_failure:
diff --git a/src/test/perl/PostgreSQL/Test/Cluster.pm b/src/test/perl/PostgreSQL/Test/Cluster.pm
index 5e161dbee60..4d449c35de9 100644
--- a/src/test/perl/PostgreSQL/Test/Cluster.pm
+++ b/src/test/perl/PostgreSQL/Test/Cluster.pm
@@ -522,8 +522,50 @@ sub init
mkdir $self->backup_dir;
mkdir $self->archive_dir;
- PostgreSQL::Test::Utils::system_or_bail('initdb', '-D', $pgdata, '-A',
- 'trust', '-N', @{ $params{extra} });
+ # If available and if there aren't any parameters, use a previously
+ # initdb'd cluster as a template by copying it. For a lot of tests, that's
+ # substantially cheaper. Do so only if there aren't parameters, it doesn't
+ # seem worth figuring out whether they affect compatibility.
+ #
+ # There's very similar code in pg_regress.c, but we can't easily
+ # deduplicate it until we require perl at build time.
+ if (defined $params{extra} or !defined $ENV{INITDB_TEMPLATE})
+ {
+ note("initializing database system by running initdb");
+ PostgreSQL::Test::Utils::system_or_bail('initdb', '-D', $pgdata, '-A',
+ 'trust', '-N', @{ $params{extra} });
+ }
+ else
+ {
+ my @copycmd;
+ my $expected_exitcode;
+
+ note("initializing database system by copying initdb template");
+
+ if ($PostgreSQL::Test::Utils::windows_os)
+ {
+ @copycmd = qw(robocopy /E /NJS /NJH /NFL /NDL /NP);
+ $expected_exitcode = 1; # 1 denotes files were copied
+ }
+ else
+ {
+ @copycmd = qw(cp -a);
+ $expected_exitcode = 0;
+ }
+
+ @copycmd = (@copycmd, $ENV{INITDB_TEMPLATE}, $pgdata);
+
+ my $ret = PostgreSQL::Test::Utils::system_log(@copycmd);
+
+ # See http://perldoc.perl.org/perlvar.html#%24CHILD_ERROR
+ if ($ret & 127 or $ret >> 8 != $expected_exitcode)
+ {
+ BAIL_OUT(
+ sprintf("failed to execute command \"%s\": $ret",
+ join(" ", @copycmd)));
+ }
+ }
+
PostgreSQL::Test::Utils::system_or_bail($ENV{PG_REGRESS},
'--config-auth', $pgdata, @{ $params{auth_extra} });
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index b68632320a7..407e3915cec 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -2295,6 +2295,7 @@ regression_main(int argc, char *argv[],
FILE *pg_conf;
const char *env_wait;
int wait_seconds;
+ const char *initdb_template_dir;
/*
* Prepare the temp instance
@@ -2316,25 +2317,64 @@ regression_main(int argc, char *argv[],
if (!directory_exists(buf))
make_directory(buf);
- /* initdb */
initStringInfo(&cmd);
- appendStringInfo(&cmd,
- "\"%s%sinitdb\" -D \"%s/data\" --no-clean --no-sync",
- bindir ? bindir : "",
- bindir ? "/" : "",
- temp_instance);
- if (debug)
- appendStringInfo(&cmd, " --debug");
- if (nolocale)
- appendStringInfo(&cmd, " --no-locale");
- appendStringInfo(&cmd, " > \"%s/log/initdb.log\" 2>&1", outputdir);
- fflush(NULL);
- if (system(cmd.data))
+
+ /*
+ * Create data directory.
+ *
+ * If available, use a previously initdb'd cluster as a template by
+ * copying it. For a lot of tests, that's substantially cheaper.
+ *
+ * There's very similar code in Cluster.pm, but we can't easily de
+ * duplicate it until we require perl at build time.
+ */
+ initdb_template_dir = getenv("INITDB_TEMPLATE");
+ if (initdb_template_dir == NULL || nolocale || debug)
{
- bail("initdb failed\n"
- "# Examine \"%s/log/initdb.log\" for the reason.\n"
- "# Command was: %s",
- outputdir, cmd.data);
+ note("initializing database system by running initdb");
+
+ appendStringInfo(&cmd,
+ "\"%s%sinitdb\" -D \"%s/data\" --no-clean --no-sync",
+ bindir ? bindir : "",
+ bindir ? "/" : "",
+ temp_instance);
+ if (debug)
+ appendStringInfo(&cmd, " --debug");
+ if (nolocale)
+ appendStringInfo(&cmd, " --no-locale");
+ appendStringInfo(&cmd, " > \"%s/log/initdb.log\" 2>&1", outputdir);
+ fflush(NULL);
+ if (system(cmd.data))
+ {
+ bail("initdb failed\n"
+ "# Examine \"%s/log/initdb.log\" for the reason.\n"
+ "# Command was: %s",
+ outputdir, cmd.data);
+ }
+ }
+ else
+ {
+#ifndef WIN32
+ const char *copycmd = "cp -a \"%s\" \"%s/data\"";
+ int expected_exitcode = 0;
+#else
+ const char *copycmd = "robocopy /E /NJS /NJH /NFL /NDL /NP \"%s\" \"%s/data\"";
+ int expected_exitcode = 1; /* 1 denotes files were copied */
+#endif
+
+ note("initializing database system by copying initdb template");
+
+ appendStringInfo(&cmd,
+ copycmd,
+ initdb_template_dir,
+ temp_instance);
+ if (system(cmd.data) != expected_exitcode)
+ {
+ bail("copying of initdb template failed\n"
+ "# Examine \"%s/log/initdb.log\" for the reason.\n"
+ "# Command was: %s",
+ outputdir, cmd.data);
+ }
}
pfree(cmd.data);
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index df9f721a41a..0b4ca0eb6ae 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -397,30 +397,6 @@ check: temp-install
.PHONY: temp-install
-temp-install: | submake-generated-headers
-ifndef NO_TEMP_INSTALL
-ifneq ($(abs_top_builddir),)
-ifeq ($(MAKELEVEL),0)
- rm -rf '$(abs_top_builddir)'/tmp_install
- $(MKDIR_P) '$(abs_top_builddir)'/tmp_install/log
- $(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install install >'$(abs_top_builddir)'/tmp_install/log/install.log 2>&1
- $(MAKE) -j1 $(if $(CHECKPREP_TOP),-C $(CHECKPREP_TOP),) checkprep >>'$(abs_top_builddir)'/tmp_install/log/install.log 2>&1
-endif
-endif
-endif
-
-# Tasks to run serially at the end of temp-install. Some EXTRA_INSTALL
-# entries appear more than once in the tree, and parallel installs of the same
-# file can fail with EEXIST.
-checkprep:
- $(if $(EXTRA_INSTALL),for extra in $(EXTRA_INSTALL); do $(MAKE) -C '$(top_builddir)'/$$extra DESTDIR='$(abs_top_builddir)'/tmp_install install || exit; done)
-
-PROVE = @PROVE@
-# There are common routines in src/test/perl, and some test suites have
-# extra perl modules in their own directory.
-PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/ -I $(srcdir)
-# User-supplied prove flags such as --verbose can be provided in PROVE_FLAGS.
-PROVE_FLAGS =
# prepend to path if already set, else just set it
define add_to_path
@@ -437,8 +413,36 @@ ld_library_path_var = LD_LIBRARY_PATH
with_temp_install = \
PATH="$(abs_top_builddir)/tmp_install$(bindir):$(CURDIR):$$PATH" \
$(call add_to_path,$(strip $(ld_library_path_var)),$(abs_top_builddir)/tmp_install$(libdir)) \
+ INITDB_TEMPLATE='$(abs_top_builddir)'/tmp_install/initdb-template \
$(with_temp_install_extra)
+temp-install: | submake-generated-headers
+ifndef NO_TEMP_INSTALL
+ifneq ($(abs_top_builddir),)
+ifeq ($(MAKELEVEL),0)
+ rm -rf '$(abs_top_builddir)'/tmp_install
+ $(MKDIR_P) '$(abs_top_builddir)'/tmp_install/log
+ $(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install install >'$(abs_top_builddir)'/tmp_install/log/install.log 2>&1
+ $(MAKE) -j1 $(if $(CHECKPREP_TOP),-C $(CHECKPREP_TOP),) checkprep >>'$(abs_top_builddir)'/tmp_install/log/install.log 2>&1
+
+ $(with_temp_install) initdb -A trust -N --no-instructions '$(abs_top_builddir)'/tmp_install/initdb-template >>'$(abs_top_builddir)'/tmp_install/log/initdb-template.log 2>&1
+endif
+endif
+endif
+
+# Tasks to run serially at the end of temp-install. Some EXTRA_INSTALL
+# entries appear more than once in the tree, and parallel installs of the same
+# file can fail with EEXIST.
+checkprep:
+ $(if $(EXTRA_INSTALL),for extra in $(EXTRA_INSTALL); do $(MAKE) -C '$(top_builddir)'/$$extra DESTDIR='$(abs_top_builddir)'/tmp_install install || exit; done)
+
+PROVE = @PROVE@
+# There are common routines in src/test/perl, and some test suites have
+# extra perl modules in their own directory.
+PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/ -I $(srcdir)
+# User-supplied prove flags such as --verbose can be provided in PROVE_FLAGS.
+PROVE_FLAGS =
+
ifeq ($(enable_tap_tests),yes)
ifndef PGXS
--
2.38.0
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
@ 2023-08-05 20:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-08-05 22:26 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
1 sibling, 1 reply; 15+ messages in thread
From: Tom Lane @ 2023-08-05 20:58 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Thomas Munro <thomas.munro@gmail.com>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Times for running all tests under meson, on my workstation (20 cores / 40
> threads):
> cassert build -O2:
> Before:
> real 0m44.638s
> user 7m58.780s
> sys 2m48.773s
> After:
> real 0m38.938s
> user 2m37.615s
> sys 2m0.570s
Impressive results. Even though your bottom-line time doesn't change that
much, the big reduction in CPU time should translate to a nice speedup
on slower buildfarm animals.
(Disclaimer: I've not read the patch.)
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-05 20:58 ` Re: initdb caching during tests Tom Lane <tgl@sss.pgh.pa.us>
@ 2023-08-05 22:26 ` Andres Freund <andres@anarazel.de>
0 siblings, 0 replies; 15+ messages in thread
From: Andres Freund @ 2023-08-05 22:26 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thomas Munro <thomas.munro@gmail.com>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
Hi,
On 2023-08-05 16:58:38 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Times for running all tests under meson, on my workstation (20 cores / 40
> > threads):
>
> > cassert build -O2:
>
> > Before:
> > real 0m44.638s
> > user 7m58.780s
> > sys 2m48.773s
>
> > After:
> > real 0m38.938s
> > user 2m37.615s
> > sys 2m0.570s
>
> Impressive results. Even though your bottom-line time doesn't change that
> much
Unfortunately we have a few tests that take quite a while - for those the
initdb removal doesn't make that much of a difference. Particularly because
this machine has enough CPUs to not be fully busy except for the first few
seconds...
E.g. for a run with the patch applied:
258/265 postgresql:pg_basebackup / pg_basebackup/010_pg_basebackup OK 16.58s 187 subtests passed
259/265 postgresql:subscription / subscription/100_bugs OK 6.69s 12 subtests passed
260/265 postgresql:regress / regress/regress OK 24.95s 215 subtests passed
261/265 postgresql:ssl / ssl/001_ssltests OK 7.97s 205 subtests passed
262/265 postgresql:pg_dump / pg_dump/002_pg_dump OK 19.65s 11262 subtests passed
263/265 postgresql:recovery / recovery/027_stream_regress OK 29.34s 6 subtests passed
264/265 postgresql:isolation / isolation/isolation OK 33.94s 112 subtests passed
265/265 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade OK 38.22s 18 subtests passed
The pg_upgrade test is faster in isolation (29s), but not that much. The
overall runtime is reduces due to the reduced "competing" cpu usage, but other
than that...
Looking at where the time is spent when running the pg_upgrade test on its own:
grep -E '^\[' testrun/pg_upgrade/002_pg_upgrade/log/regress_log_002_pg_upgrade |sed -E -e 's/.*\(([0-9.]+)s\)(.*)/\1 \2/g'|sort -n -r
cassert:
13.094 ok 5 - regression tests pass
6.147 ok 14 - run of pg_upgrade for new instance
2.340 ok 6 - dump before running pg_upgrade
1.638 ok 17 - dump after running pg_upgrade
1.375 ok 12 - run of pg_upgrade --check for new instance
0.798 ok 1 - check locales in original cluster
0.371 ok 9 - invalid database causes failure status (got 1 vs expected 1)
0.149 ok 7 - run of pg_upgrade --check for new instance with incorrect binary path
0.131 ok 16 - check that locales in new cluster match original cluster
optimized:
8.372 ok 5 - regression tests pass
3.641 ok 14 - run of pg_upgrade for new instance
1.371 ok 12 - run of pg_upgrade --check for new instance
1.104 ok 6 - dump before running pg_upgrade
0.636 ok 17 - dump after running pg_upgrade
0.594 ok 1 - check locales in original cluster
0.359 ok 9 - invalid database causes failure status (got 1 vs expected 1)
0.148 ok 7 - run of pg_upgrade --check for new instance with incorrect binary path
0.127 ok 16 - check that locales in new cluster match original cluster
The time for "dump before running pg_upgrade" is misleadingly high - there's
no output between starting initdb and the dump, so the timing includes initdb
and a bunch of other work. But it's still not fast (1.637s) after.
A small factor is that the initdb times are not insignificant, because the
template initdb can't be used due to a bunch of parameters passed to initdb :)
> the big reduction in CPU time should translate to a nice speedup on slower
> buildfarm animals.
Yea. It's a particularly large win when using valgrind. Under valgrind, a very
large portion of the time for many tests is just spent doing initdb... So I am
hoping to see some nice gains for skink.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
@ 2023-08-22 21:47 ` Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
1 sibling, 1 reply; 15+ messages in thread
From: Daniel Gustafsson @ 2023-08-22 21:47 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
> On 5 Aug 2023, at 21:56, Andres Freund <andres@anarazel.de> wrote:
> We have some issues with CI on macos and windows being too expensive (more on
> that soon in a separate email), which reminded me of this thread (with
> original title: [1])
>
> I've attached a somewhat cleaned up version of the patch to cache initdb
> across runs. The results are still fairly impressive in my opinion.
>
> One thing I do not like, but don't have a good idea for how to improve, is
> that there's a bunch of duplicated logic in pg_regress.c and Cluster.pm. I've
> tried to move that into initdb.c itself, but that ends up pretty ugly, because
> we need to be a lot more careful about checking whether options are compatible
> etc. I've also thought about just putting this into a separate perl script,
> but right now we still allow basic regression tests without perl being
> available. So I concluded that for now just having the copies is the best
> answer.
I had a look at this today and have been running a lot of tests with it without
finding anything that breaks. The duplicated code is unfortunate, but after
playing around with some options I agree that it's likely the best option.
While looking I did venture down the rabbithole of making it support extra
params as well, but I don't think moving the goalposts there is doing us any
favors, it's clearly chasing diminishing returns.
My only small gripe is that I keep thinking about template databases for CREATE
DATABASE when reading the error messages in this patch, which is clearly not
related to what this does.
+ note("initializing database system by copying initdb template");
I personally would've used cache instead of template in the user facing parts
to keep concepts separated, but thats personal taste.
All in all, I think this is committable as is.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
@ 2023-08-23 01:17 ` Andres Freund <andres@anarazel.de>
2023-08-23 08:10 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 15+ messages in thread
From: Andres Freund @ 2023-08-23 01:17 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
Hi,
On 2023-08-22 23:47:24 +0200, Daniel Gustafsson wrote:
> I had a look at this today and have been running a lot of tests with it without
> finding anything that breaks.
Thanks!
> The duplicated code is unfortunate, but after playing around with some
> options I agree that it's likely the best option.
Good and bad to hear :)
> While looking I did venture down the rabbithole of making it support extra
> params as well, but I don't think moving the goalposts there is doing us any
> favors, it's clearly chasing diminishing returns.
Agreed. I also went down that rabbithole, but it quickly gets a lot more code
and complexity - and there just aren't that many tests using non-default
options.
> My only small gripe is that I keep thinking about template databases for CREATE
> DATABASE when reading the error messages in this patch, which is clearly not
> related to what this does.
>
> + note("initializing database system by copying initdb template");
>
> I personally would've used cache instead of template in the user facing parts
> to keep concepts separated, but thats personal taste.
I am going back and forth on that one (as one can notice with $subject). It
doesn't quite seem like a cache, as it's not "created" on demand and only
usable when the exactly same parameters are used repeatedly. But template is
overloaded as you say...
> All in all, I think this is committable as is.
Cool. Planning to do that tomorrow. We can easily extend / adjust this later,
it just affects testing infrastructure.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
@ 2023-08-23 08:10 ` Daniel Gustafsson <daniel@yesql.se>
2023-08-24 22:10 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 15+ messages in thread
From: Daniel Gustafsson @ 2023-08-23 08:10 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
> On 23 Aug 2023, at 03:17, Andres Freund <andres@anarazel.de> wrote:
> On 2023-08-22 23:47:24 +0200, Daniel Gustafsson wrote:
>> My only small gripe is that I keep thinking about template databases for CREATE
>> DATABASE when reading the error messages in this patch, which is clearly not
>> related to what this does.
>>
>> + note("initializing database system by copying initdb template");
>>
>> I personally would've used cache instead of template in the user facing parts
>> to keep concepts separated, but thats personal taste.
>
> I am going back and forth on that one (as one can notice with $subject). It
> doesn't quite seem like a cache, as it's not "created" on demand and only
> usable when the exactly same parameters are used repeatedly. But template is
> overloaded as you say...
That's a fair point, cache is not a good word to describe a stored copy of
something prefabricated. Let's go with template, we can always refine in-tree
if a better wording comes along.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-23 08:10 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
@ 2023-08-24 22:10 ` Andres Freund <andres@anarazel.de>
2023-08-25 05:50 ` Re: initdb caching during tests Thomas Munro <thomas.munro@gmail.com>
2023-08-25 16:29 ` Re: initdb caching during tests Nathan Bossart <nathandbossart@gmail.com>
2023-12-07 13:50 ` Re: initdb caching during tests Matthias van de Meent <boekewurm+postgres@gmail.com>
0 siblings, 3 replies; 15+ messages in thread
From: Andres Freund @ 2023-08-24 22:10 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
Hi,
On 2023-08-23 10:10:31 +0200, Daniel Gustafsson wrote:
> > On 23 Aug 2023, at 03:17, Andres Freund <andres@anarazel.de> wrote:
> > On 2023-08-22 23:47:24 +0200, Daniel Gustafsson wrote:
>
> >> My only small gripe is that I keep thinking about template databases for CREATE
> >> DATABASE when reading the error messages in this patch, which is clearly not
> >> related to what this does.
> >>
> >> + note("initializing database system by copying initdb template");
> >>
> >> I personally would've used cache instead of template in the user facing parts
> >> to keep concepts separated, but thats personal taste.
> >
> > I am going back and forth on that one (as one can notice with $subject). It
> > doesn't quite seem like a cache, as it's not "created" on demand and only
> > usable when the exactly same parameters are used repeatedly. But template is
> > overloaded as you say...
>
> That's a fair point, cache is not a good word to describe a stored copy of
> something prefabricated. Let's go with template, we can always refine in-tree
> if a better wording comes along.
Cool. Pushed that way. Only change I made is to redirect the output of cp
(and/or robocopy) in pg_regress, similar to how that was done for initdb
proper.
Let's see what the buildfarm says - it's not inconceivable that it'll show
some issues.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-23 08:10 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-24 22:10 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
@ 2023-08-25 05:50 ` Thomas Munro <thomas.munro@gmail.com>
2023-08-25 07:00 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2 siblings, 1 reply; 15+ messages in thread
From: Thomas Munro @ 2023-08-25 05:50 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Daniel Gustafsson <daniel@yesql.se>; Tom Lane <tgl@sss.pgh.pa.us>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On Fri, Aug 25, 2023 at 10:10 AM Andres Freund <andres@anarazel.de> wrote:
> Let's see what the buildfarm says - it's not inconceivable that it'll show
> some issues.
Apparently Solaris doesn't like "cp -a", per animal "margay". I think
"cp -RPp" should be enough everywhere?
https://docs.oracle.com/cd/E88353_01/html/E37839/cp-1.html
https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/utilities/cp.html
Attachments:
[text/x-patch] 0001-Avoid-non-POSIX-cp-flags.patch (1.1K, ../../CA+hUKGL10AoQVMMqgOJ8CTjoz9MLidD8ik2e8PibzLNMz0+aRg@mail.gmail.com/2-0001-Avoid-non-POSIX-cp-flags.patch)
download | inline diff:
From fd6c558e6bd43eef40d633ace763d8a2088c2509 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Fri, 25 Aug 2023 17:30:48 +1200
Subject: [PATCH] Avoid non-POSIX cp flags.
Commit 252dcb32 introduced cp -a, but apparently Solaris doesn't like
it. Use cp -RPp instead.
diff --git a/src/test/perl/PostgreSQL/Test/Cluster.pm b/src/test/perl/PostgreSQL/Test/Cluster.pm
index 426f94ff09..227c34ab4d 100644
--- a/src/test/perl/PostgreSQL/Test/Cluster.pm
+++ b/src/test/perl/PostgreSQL/Test/Cluster.pm
@@ -549,7 +549,7 @@ sub init
}
else
{
- @copycmd = qw(cp -a);
+ @copycmd = qw(cp -RPp);
$expected_exitcode = 0;
}
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index 06674141a3..ec67588cf5 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -2355,7 +2355,7 @@ regression_main(int argc, char *argv[],
else
{
#ifndef WIN32
- const char *copycmd = "cp -a \"%s\" \"%s/data\"";
+ const char *copycmd = "cp -RPp \"%s\" \"%s/data\"";
int expected_exitcode = 0;
#else
const char *copycmd = "robocopy /E /NJS /NJH /NFL /NDL /NP \"%s\" \"%s/data\"";
--
2.39.2
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-23 08:10 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-24 22:10 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-25 05:50 ` Re: initdb caching during tests Thomas Munro <thomas.munro@gmail.com>
@ 2023-08-25 07:00 ` Daniel Gustafsson <daniel@yesql.se>
2023-08-25 13:57 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 15+ messages in thread
From: Daniel Gustafsson @ 2023-08-25 07:00 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
> On 25 Aug 2023, at 07:50, Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Fri, Aug 25, 2023 at 10:10 AM Andres Freund <andres@anarazel.de> wrote:
>> Let's see what the buildfarm says - it's not inconceivable that it'll show
>> some issues.
>
> Apparently Solaris doesn't like "cp -a", per animal "margay". I think
> "cp -RPp" should be enough everywhere?
Agreed, AFAICT that should work equally well on all supported platforms.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-23 08:10 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-24 22:10 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-25 05:50 ` Re: initdb caching during tests Thomas Munro <thomas.munro@gmail.com>
2023-08-25 07:00 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
@ 2023-08-25 13:57 ` Andres Freund <andres@anarazel.de>
0 siblings, 0 replies; 15+ messages in thread
From: Andres Freund @ 2023-08-25 13:57 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Thomas Munro <thomas.munro@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
Hi,
On 2023-08-25 09:00:24 +0200, Daniel Gustafsson wrote:
> > On 25 Aug 2023, at 07:50, Thomas Munro <thomas.munro@gmail.com> wrote:
> >
> > On Fri, Aug 25, 2023 at 10:10 AM Andres Freund <andres@anarazel.de> wrote:
> >> Let's see what the buildfarm says - it's not inconceivable that it'll show
> >> some issues.
> >
> > Apparently Solaris doesn't like "cp -a", per animal "margay". I think
> > "cp -RPp" should be enough everywhere?
Thanks for noticing the issue and submitting the patch.
> Agreed, AFAICT that should work equally well on all supported platforms.
Also agreed. Unsurprisingly, CI didn't find anything on the tested platforms.
Pushed.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-23 08:10 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-24 22:10 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
@ 2023-08-25 16:29 ` Nathan Bossart <nathandbossart@gmail.com>
2 siblings, 0 replies; 15+ messages in thread
From: Nathan Bossart @ 2023-08-25 16:29 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Daniel Gustafsson <daniel@yesql.se>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On Thu, Aug 24, 2023 at 03:10:00PM -0700, Andres Freund wrote:
> Cool. Pushed that way.
I just noticed the tests running about 30% faster on my machine due to
this. Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-23 08:10 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-24 22:10 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
@ 2023-12-07 13:50 ` Matthias van de Meent <boekewurm+postgres@gmail.com>
2023-12-07 14:06 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2 siblings, 1 reply; 15+ messages in thread
From: Matthias van de Meent @ 2023-12-07 13:50 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Daniel Gustafsson <daniel@yesql.se>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On Fri, 25 Aug 2023 at 00:16, Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2023-08-23 10:10:31 +0200, Daniel Gustafsson wrote:
> > > On 23 Aug 2023, at 03:17, Andres Freund <andres@anarazel.de> wrote:
> > > On 2023-08-22 23:47:24 +0200, Daniel Gustafsson wrote:
> >
> > >> My only small gripe is that I keep thinking about template databases for CREATE
> > >> DATABASE when reading the error messages in this patch, which is clearly not
> > >> related to what this does.
> > >>
> > >> + note("initializing database system by copying initdb template");
> > >>
> > >> I personally would've used cache instead of template in the user facing parts
> > >> to keep concepts separated, but thats personal taste.
> > >
> > > I am going back and forth on that one (as one can notice with $subject). It
> > > doesn't quite seem like a cache, as it's not "created" on demand and only
> > > usable when the exactly same parameters are used repeatedly. But template is
> > > overloaded as you say...
> >
> > That's a fair point, cache is not a good word to describe a stored copy of
> > something prefabricated. Let's go with template, we can always refine in-tree
> > if a better wording comes along.
>
> Cool. Pushed that way. Only change I made is to redirect the output of cp
> (and/or robocopy) in pg_regress, similar to how that was done for initdb
> proper.
While working on some things that are prone to breaking initdb, I
noticed that this template isn't generated with --no-clean, while
pg_regress does do that. This meant `make check` didn't have any
meaningful debuggable output when I broke the processes in initdb,
which is undesirable.
Attached a patch that fixes this for both make and meson, by adding
--no-clean to the initdb template.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
Attachments:
[application/octet-stream] v1-0001-Don-t-remove-initdb-template-when-initdb-fails.patch (1.7K, ../../CAEze2WhSTjfK_M+Ea4GSQp8odrEOaQS8HyORd1TJUEiyXaB+rw@mail.gmail.com/2-v1-0001-Don-t-remove-initdb-template-when-initdb-fails.patch)
download | inline diff:
From bd727a7cd560140a1646e3afaba237dfb6a92dc4 Mon Sep 17 00:00:00 2001
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
Date: Thu, 7 Dec 2023 14:47:32 +0100
Subject: [PATCH v1] Don't remove initdb template when initdb fails
pg_regress doesn't do that either, so keep a copy around
to allow us to debug those issues.
---
meson.build | 2 +-
src/Makefile.global.in | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 0095fb183a..5bae1eb04c 100644
--- a/meson.build
+++ b/meson.build
@@ -3112,7 +3112,7 @@ sys.exit(sp.returncode)
''',
test_initdb_template,
temp_install_bindir / 'initdb',
- '-A', 'trust', '-N', '--no-instructions', '--no-locale'
+ '-A', 'trust', '-N', '--no-instructions', '--no-locale', '--no-clean'
],
priority: setup_tests_priority - 1,
timeout: 300,
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index b3ca6392a6..06588b1c47 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -423,7 +423,7 @@ ifeq ($(MAKELEVEL),0)
$(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install install >'$(abs_top_builddir)'/tmp_install/log/install.log 2>&1
$(MAKE) -j1 $(if $(CHECKPREP_TOP),-C $(CHECKPREP_TOP),) checkprep >>'$(abs_top_builddir)'/tmp_install/log/install.log 2>&1
- $(with_temp_install) initdb -A trust -N --no-instructions --no-locale '$(abs_top_builddir)'/tmp_install/initdb-template >>'$(abs_top_builddir)'/tmp_install/log/initdb-template.log 2>&1
+ $(with_temp_install) initdb -A trust -N --no-instructions --no-locale --no-clean '$(abs_top_builddir)'/tmp_install/initdb-template >>'$(abs_top_builddir)'/tmp_install/log/initdb-template.log 2>&1
endif
endif
endif
--
2.40.1
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-23 08:10 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-24 22:10 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-12-07 13:50 ` Re: initdb caching during tests Matthias van de Meent <boekewurm+postgres@gmail.com>
@ 2023-12-07 14:06 ` Daniel Gustafsson <daniel@yesql.se>
2023-12-07 14:27 ` Re: initdb caching during tests Matthias van de Meent <boekewurm+postgres@gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Daniel Gustafsson @ 2023-12-07 14:06 UTC (permalink / raw)
To: Matthias van de Meent <boekewurm+postgres@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
> On 7 Dec 2023, at 14:50, Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
> Attached a patch that fixes this for both make and meson, by adding
> --no-clean to the initdb template.
Makes sense. While in there I think we should rename -N to the long optoin
--no-sync to make it easier to grep for and make the buildfiles more
self-documenting.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-23 08:10 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-24 22:10 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-12-07 13:50 ` Re: initdb caching during tests Matthias van de Meent <boekewurm+postgres@gmail.com>
2023-12-07 14:06 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
@ 2023-12-07 14:27 ` Matthias van de Meent <boekewurm+postgres@gmail.com>
2023-12-08 12:59 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 15+ messages in thread
From: Matthias van de Meent @ 2023-12-07 14:27 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
On Thu, 7 Dec 2023 at 15:06, Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 7 Dec 2023, at 14:50, Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
>
> > Attached a patch that fixes this for both make and meson, by adding
> > --no-clean to the initdb template.
>
> Makes sense. While in there I think we should rename -N to the long optoin
> --no-sync to make it easier to grep for and make the buildfiles more
> self-documenting.
Then that'd be the attached patch, which also includes --auth instead
of -A, for the same reason as -N vs --no-sync
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
Attachments:
[application/octet-stream] v2-0001-Don-t-remove-initdb-template-when-initdb-fails.patch (1.9K, ../../CAEze2WjXrDKb5N6jf9-qQg7JRhZtzCk5V97x_+rsraBgX2PnQg@mail.gmail.com/2-v2-0001-Don-t-remove-initdb-template-when-initdb-fails.patch)
download | inline diff:
From a77293d22bc58fe23bdc9bdec64ac9b2f153718b Mon Sep 17 00:00:00 2001
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
Date: Thu, 7 Dec 2023 14:47:32 +0100
Subject: [PATCH v2] Don't remove initdb template when initdb fails
pg_regress doesn't do that either, so keep a copy around
to allow us to debug those issues.
While we're here, use the long options for initdb, to
make this code more self-documenting.
Reviewed-by: Daniel Gustafsson
---
meson.build | 3 ++-
src/Makefile.global.in | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 0095fb183a..502f511588 100644
--- a/meson.build
+++ b/meson.build
@@ -3112,7 +3112,8 @@ sys.exit(sp.returncode)
''',
test_initdb_template,
temp_install_bindir / 'initdb',
- '-A', 'trust', '-N', '--no-instructions', '--no-locale'
+ '--auth', 'trust', '--no-sync', '--no-instructions', '--no-locale',
+ '--no-clean'
],
priority: setup_tests_priority - 1,
timeout: 300,
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index b3ca6392a6..104e5de0fe 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -423,7 +423,7 @@ ifeq ($(MAKELEVEL),0)
$(MAKE) -C '$(top_builddir)' DESTDIR='$(abs_top_builddir)'/tmp_install install >'$(abs_top_builddir)'/tmp_install/log/install.log 2>&1
$(MAKE) -j1 $(if $(CHECKPREP_TOP),-C $(CHECKPREP_TOP),) checkprep >>'$(abs_top_builddir)'/tmp_install/log/install.log 2>&1
- $(with_temp_install) initdb -A trust -N --no-instructions --no-locale '$(abs_top_builddir)'/tmp_install/initdb-template >>'$(abs_top_builddir)'/tmp_install/log/initdb-template.log 2>&1
+ $(with_temp_install) initdb --auth trust --no-sync --no-instructions --no-locale --no-clean '$(abs_top_builddir)'/tmp_install/initdb-template >>'$(abs_top_builddir)'/tmp_install/log/initdb-template.log 2>&1
endif
endif
endif
--
2.40.1
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: initdb caching during tests
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-23 08:10 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-08-24 22:10 ` Re: initdb caching during tests Andres Freund <andres@anarazel.de>
2023-12-07 13:50 ` Re: initdb caching during tests Matthias van de Meent <boekewurm+postgres@gmail.com>
2023-12-07 14:06 ` Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
2023-12-07 14:27 ` Re: initdb caching during tests Matthias van de Meent <boekewurm+postgres@gmail.com>
@ 2023-12-08 12:59 ` Daniel Gustafsson <daniel@yesql.se>
0 siblings, 0 replies; 15+ messages in thread
From: Daniel Gustafsson @ 2023-12-08 12:59 UTC (permalink / raw)
To: Matthias van de Meent <boekewurm+postgres@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; Robert Haas <robertmhaas@gmail.com>; pgsql-hackers
> On 7 Dec 2023, at 15:27, Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
> Then that'd be the attached patch, which also includes --auth instead
> of -A, for the same reason as -N vs --no-sync
Applied to master, thanks!
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2023-12-08 12:59 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-08-05 19:56 initdb caching during tests Andres Freund <andres@anarazel.de>
2023-08-05 20:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-08-05 22:26 ` Andres Freund <andres@anarazel.de>
2023-08-22 21:47 ` Daniel Gustafsson <daniel@yesql.se>
2023-08-23 01:17 ` Andres Freund <andres@anarazel.de>
2023-08-23 08:10 ` Daniel Gustafsson <daniel@yesql.se>
2023-08-24 22:10 ` Andres Freund <andres@anarazel.de>
2023-08-25 05:50 ` Thomas Munro <thomas.munro@gmail.com>
2023-08-25 07:00 ` Daniel Gustafsson <daniel@yesql.se>
2023-08-25 13:57 ` Andres Freund <andres@anarazel.de>
2023-08-25 16:29 ` Nathan Bossart <nathandbossart@gmail.com>
2023-12-07 13:50 ` Matthias van de Meent <boekewurm+postgres@gmail.com>
2023-12-07 14:06 ` Daniel Gustafsson <daniel@yesql.se>
2023-12-07 14:27 ` Matthias van de Meent <boekewurm+postgres@gmail.com>
2023-12-08 12:59 ` Daniel Gustafsson <daniel@yesql.se>
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