From 5d9f5c20dd29ac9dde19c283a821709839fae102 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 22 Sep 2004 19:11:19 +0000 Subject: [PATCH] Issue a CHECKPOINT just after creating the regression database. Without this, it's hard to debug core-dump test failures, because WAL replay will enthusiastically remove the core file (along with the rest of the regression database directory). Per recent discussion, not to mention bitter experience. --- src/test/regress/pg_regress.sh | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/test/regress/pg_regress.sh b/src/test/regress/pg_regress.sh index a9f0dc423c..567975f919 100644 --- a/src/test/regress/pg_regress.sh +++ b/src/test/regress/pg_regress.sh @@ -1,5 +1,5 @@ #! /bin/sh -# $PostgreSQL: pgsql/src/test/regress/pg_regress.sh,v 1.46 2004/08/10 22:24:06 tgl Exp $ +# $PostgreSQL: pgsql/src/test/regress/pg_regress.sh,v 1.47 2004/09/22 19:11:19 tgl Exp $ me=`basename $0` : ${TMPDIR=/tmp} @@ -510,6 +510,9 @@ fi # Create the regression database # We use template0 so that any installation-local cruft in template1 # will not mess up the tests. +# Note: the reason for checkpointing just after creating the new DB is so +# that if we get a backend core dump during the tests, WAL replay won't +# remove the core file. # ---------- message "creating database \"$dbname\"" @@ -520,6 +523,7 @@ if [ $? -ne 0 ]; then fi "$bindir/psql" $psql_options -c "\ +checkpoint; alter database \"$dbname\" set lc_messages to 'C'; alter database \"$dbname\" set lc_monetary to 'C'; alter database \"$dbname\" set lc_numeric to 'C';