database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-24 10:47:04 +03:00
Code

Force a checkpoint before committing a CREATE DATABASE command. This

Browse Source 
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.
This commit is contained in:
Tom Lane 2005-06-25 22:47:29 +00:00
parent 3acca18d28
commit fbcbc5d06f
2 changed files with 44 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
doc/src/sgml/backup.sgml
View File

@ -1,5 +1,5 @@
<!-- <!--
$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.68 2005/06/21 20:45:43 tgl Exp $ $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.69 2005/06/25 22:47:28 tgl Exp $
--> -->
<chapter id="backup"> <chapter id="backup">
<title>Backup and Restore</title> <title>Backup and Restore</title>
@ -1119,6 +1119,18 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
</para> </para>
</listitem> </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> <listitem>
<para> <para>
<command>CREATE TABLESPACE</> commands are WAL-logged with the literal <command>CREATE TABLESPACE</> commands are WAL-logged with the literal

32
src/backend/commands/dbcommands.c
View File

@ -15,7 +15,7 @@
* *
* *
* IDENTIFICATION * IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/commands/dbcommands.c,v 1.160 2005/06/21 04:02:31 tgl Exp $ * $PostgreSQL: pgsql/src/backend/commands/dbcommands.c,v 1.161 2005/06/25 22:47:29 tgl Exp $
* *
*------------------------------------------------------------------------- *-------------------------------------------------------------------------
*/ */
@ -514,6 +514,36 @@ createdb(const CreatedbStmt *stmt)
/* Close pg_database, but keep exclusive lock till commit */ /* Close pg_database, but keep exclusive lock till commit */
heap_close(pg_database_rel, NoLock); 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);
/* /*
* Set flag to update flat database file at commit. * Set flag to update flat database file at commit.
*/ */