]> git.ipfire.org Git - thirdparty/postgresql.git/commitdiff
Force a checkpoint before committing a CREATE DATABASE command. This
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 25 Jun 2005 22:47:49 +0000 (22:47 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 25 Jun 2005 22:47:49 +0000 (22:47 +0000)
should fix the recent reports of "index is not a btree" failures,
as well as preventing a more obscure race condition involving changes
to a template database just after copying it with CREATE DATABASE.

doc/src/sgml/backup.sgml
src/backend/commands/dbcommands.c

index 099483766e07c6fdf2a90e9a44c45ac558ec1589..d61fe997e6fe2e6f76e97ca76df0398274eb8dd9 100644 (file)
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.54.4.5 2005/04/19 01:40:02 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.54.4.6 2005/06/25 22:47:49 tgl Exp $
 -->
 <chapter id="backup">
  <title>Backup and Restore</title>
@@ -1143,6 +1143,18 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"'  # Windows
     </para>
    </listitem>
 
+   <listitem>
+    <para>
+     If a <command>CREATE DATABASE</> command is executed while a base
+     backup is being taken, and then the template database that the
+     <command>CREATE DATABASE</> copied is modified while the base backup
+     is still in progress, it is possible that recovery will cause those
+     modifications to be propagated into the created database as well.
+     This is of course undesirable.  To avoid this risk, it is best not to
+     modify any template databases while taking a base backup.
+    </para>
+   </listitem>
+
    <listitem>
     <para>
      <command>CREATE TABLESPACE</> commands are WAL-logged with the literal
index fad0c51ce2afe0ff5d4cc97913850c46b04f0dfe..70329ce39746911d24bec8ea2d7790eb8dede315 100644 (file)
@@ -9,7 +9,7 @@
  *
  *
  * IDENTIFICATION
- *       $PostgreSQL: pgsql/src/backend/commands/dbcommands.c,v 1.148.4.2 2005/03/23 00:04:23 tgl Exp $
+ *       $PostgreSQL: pgsql/src/backend/commands/dbcommands.c,v 1.148.4.3 2005/06/25 22:47:49 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -500,6 +500,36 @@ createdb(const CreatedbStmt *stmt)
 
        /* Close pg_database, but keep exclusive lock till commit */
        heap_close(pg_database_rel, NoLock);
+
+       /*
+        * We force a checkpoint before committing.  This effectively means
+        * that committed XLOG_DBASE_CREATE operations will never need to be
+        * replayed (at least not in ordinary crash recovery; we still have
+        * to make the XLOG entry for the benefit of PITR operations).
+        * This avoids two nasty scenarios:
+        *
+        * #1: When PITR is off, we don't XLOG the contents of newly created
+        * indexes; therefore the drop-and-recreate-whole-directory behavior
+        * of DBASE_CREATE replay would lose such indexes.
+        *
+        * #2: Since we have to recopy the source database during DBASE_CREATE
+        * replay, we run the risk of copying changes in it that were committed
+        * after the original CREATE DATABASE command but before the system
+        * crash that led to the replay.  This is at least unexpected and at
+        * worst could lead to inconsistencies, eg duplicate table names.
+        *
+        * (Both of these were real bugs in releases 8.0 through 8.0.3.)
+        *
+        * In PITR replay, the first of these isn't an issue, and the second
+        * is only a risk if the CREATE DATABASE and subsequent template
+        * database change both occur while a base backup is being taken.
+        * There doesn't seem to be much we can do about that except document
+        * it as a limitation.
+        *
+        * Perhaps if we ever implement CREATE DATABASE in a less cheesy
+        * way, we can avoid this.
+        */
+       RequestCheckpoint(true);
 }