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.

1 files changed, 5 insertions, 1 deletions

diff --git a/src/test/regress/pg_regress.sh b/src/test/regress/pg_regress.sh
index a9f0dc423c3..567975f919d 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';