Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
Dilip Kumar <dilipbalaut@gmail.com>
Attachments
- v15-0001-Refactor-relmap-load-and-relmap-write-functions.patch (text/x-patch) patch v15-0001
- v15-0003-Allow-ReadBufferWithoutRelcache-to-support-unlog.patch (text/x-patch) patch v15-0003
- v15-0005-WAL-logged-CREATE-DATABASE.patch (text/x-patch) patch v15-0005
- v15-0004-New-interface-to-lock-relation-id.patch (text/x-patch) patch v15-0004
- v15-0002-Extend-relmap-interfaces.patch (text/x-patch) patch v15-0002
- v15-0006-Support-create-database-strategy-in-createdb-too.patch (text/x-patch) patch v15-0006
On Mon, Mar 14, 2022 at 10:04 PM Robert Haas <robertmhaas@gmail.com> wrote: > I think it would make sense to have two different WAL records e.g. > XLOG_DBASE_CREATE_WAL_LOG and XLOG_DBASE_CREATE_FILE_COPY. Then it's > easy to see how this could be generalized to other strategies in the > future. Done that way. In dbase_desc(), for XLOG_DBASE_CREATE_FILE_COPY I have kept the older description i.e. "copy dir" and for XLOG_DBASE_CREATE_WAL_LOG it is "create dir", because logically the first one is actually copying and the second one is just creating the directory. Do you think we should be using "copy dir file_copy" and "copy dir wal_log" in the description as well? > On Mon, Mar 14, 2022 at 12:04 PM Robert Haas <robertmhaas@gmail.com> wrote: > > I was looking at 0001 and 0002 again and realized that I swapped the > > names load_relmap_file() and read_relmap_file() from what I should > > have done. Here's a revised version. With this, read_relmap_file() and > > write_relmap_file() become functions that just read and write the file > > without touching any global variables, and load_relmap_file() is the > > function that reads data from the file and puts it into a global > > variable, which seems more sensible than the way I had it before. Okay, I have included this patch and rebased other patches on top of that. > Regarding 0003 and 0005, I'm not a fan of 'bool isunlogged'. I think > 'bool permanent' would be better (note BM_PERMANENT). This would > involve reversing true and false. Okay changed. > Regarding 0005: > > + CREATEDB_WAL_LOG = 0, > + CREATEDB_FILE_COPY = 1 > > I still think you don't need = 0 and = 1 here. Done > I'll probably go through and do a pass over the comments once you post > the next version of this. There seems to be work needed in a bunch of > places, but it probably makes more sense for me to go through and > adjust the things that seem to need it rather than listing a bunch of > changes for you to make. Sure, thanks. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
When using the WAL-logged CREATE DATABASE strategy, bulk extend.
- 3e63e8462f31 16.0 landed
- 576bb0fc9342 15.0 landed
-
Avoid using a fake relcache entry to own an SmgrRelation.
- 1b94f8f232f6 15.0 landed
- 76733b399c49 16.0 landed
-
Fix data-corruption hazard in WAL-logged CREATE DATABASE.
- 692df425b688 16.0 landed
- 811203d4aff5 15.0 landed
-
initdb: When running CREATE DATABASE, use STRATEGY = WAL_COPY.
- ad43a413c4f7 15.0 landed
-
Simplify a needlessly-complicated regular expression.
- c6863b858291 15.0 landed
-
In 020_createdb.pl, change order of command-line arguments.
- 3d067c53b26d 15.0 landed
-
Add new block-by-block strategy for CREATE DATABASE.
- 9c08aea6a309 15.0 landed
-
Fix replay of create database records on standby
- 49d9cfc68bf4 15.0 cited
-
Refactor code for reading and writing relation map files.
- 39f0c4bd670c 15.0 landed
-
Replace RelationOpenSmgr() with RelationGetSmgr().
- f10f0ae420ee 15.0 cited
-
Refactor the fsync queue for wider use.
- 3eb77eba5a51 12.0 cited