diff options
author | Robert Haas <rhaas@postgresql.org> | 2022-03-29 11:31:43 -0400 |
---|---|---|
committer | Robert Haas <rhaas@postgresql.org> | 2022-03-29 11:48:36 -0400 |
commit | 9c08aea6a3090a396be334cc58c511edab05776a (patch) | |
tree | c15e6e9fa45a18173a5bbd67ff4a4c889e616cde /src/include/commands/dbcommands_xlog.h | |
parent | bf902c13930c268388644100663f2998868b6e85 (diff) | |
download | postgresql-9c08aea6a3090a396be334cc58c511edab05776a.tar.gz postgresql-9c08aea6a3090a396be334cc58c511edab05776a.zip |
Add new block-by-block strategy for CREATE DATABASE.
Because this strategy logs changes on a block-by-block basis, it
avoids the need to checkpoint before and after the operation.
However, because it logs each changed block individually, it might
generate a lot of extra write-ahead logging if the template database
is large. Therefore, the older strategy remains available via a new
STRATEGY parameter to CREATE DATABASE, and a corresponding --strategy
option to createdb.
Somewhat controversially, this patch assembles the list of relations
to be copied to the new database by reading the pg_class relation of
the template database. Cross-database access like this isn't normally
possible, but it can be made to work here because there can't be any
connections to the database being copied, nor can it contain any
in-doubt transactions. Even so, we have to use lower-level interfaces
than normal, since the table scan and relcache interfaces will not
work for a database to which we're not connected. The advantage of
this approach is that we do not need to rely on the filesystem to
determine what ought to be copied, but instead on PostgreSQL's own
knowledge of the database structure. This avoids, for example,
copying stray files that happen to be located in the source database
directory.
Dilip Kumar, with a fairly large number of cosmetic changes by me.
Reviewed and tested by Ashutosh Sharma, Andres Freund, John Naylor,
Greg Nancarrow, Neha Sharma. Additional feedback from Bruce Momjian,
Heikki Linnakangas, Julien Rouhaud, Adam Brusselback, Kyotaro
Horiguchi, Tomas Vondra, Andrew Dunstan, Álvaro Herrera, and others.
Discussion: http://postgr.es/m/CA+TgmoYtcdxBjLh31DLxUXHxFVMPGzrU5_T=CYCvRyFHywSBUQ@mail.gmail.com
Diffstat (limited to 'src/include/commands/dbcommands_xlog.h')
-rw-r--r-- | src/include/commands/dbcommands_xlog.h | 25 |
1 files changed, 20 insertions, 5 deletions
diff --git a/src/include/commands/dbcommands_xlog.h b/src/include/commands/dbcommands_xlog.h index 593a8578a41..0ee2452feba 100644 --- a/src/include/commands/dbcommands_xlog.h +++ b/src/include/commands/dbcommands_xlog.h @@ -18,17 +18,32 @@ #include "lib/stringinfo.h" /* record types */ -#define XLOG_DBASE_CREATE 0x00 -#define XLOG_DBASE_DROP 0x10 +#define XLOG_DBASE_CREATE_FILE_COPY 0x00 +#define XLOG_DBASE_CREATE_WAL_LOG 0x10 +#define XLOG_DBASE_DROP 0x20 -typedef struct xl_dbase_create_rec +/* + * Single WAL record for an entire CREATE DATABASE operation. This is used + * by the FILE_COPY strategy. + */ +typedef struct xl_dbase_create_file_copy_rec { - /* Records copying of a single subdirectory incl. contents */ Oid db_id; Oid tablespace_id; Oid src_db_id; Oid src_tablespace_id; -} xl_dbase_create_rec; +} xl_dbase_create_file_copy_rec; + +/* + * WAL record for the beginning of a CREATE DATABASE operation, when the + * WAL_LOG strategy is used. Each individual block will be logged separately + * afterward. + */ +typedef struct xl_dbase_create_wal_log_rec +{ + Oid db_id; + Oid tablespace_id; +} xl_dbase_create_wal_log_rec; typedef struct xl_dbase_drop_rec { |