mirror of
https://github.com/postgres/postgres.git
synced 2025-04-22 23:02:54 +03:00
Force a checkpoint before committing a CREATE DATABASE command. This
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:
parent
3acca18d28
commit
fbcbc5d06f
@ -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">
|
||||
<title>Backup and Restore</title>
|
||||
@ -1119,6 +1119,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
|
||||
|
@ -15,7 +15,7 @@
|
||||
*
|
||||
*
|
||||
* 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 */
|
||||
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.
|
||||
*/
|
||||
|
Loading…
x
Reference in New Issue
Block a user