Re: proposal: CREATE DATABASE vs. (partial) CHECKPOINT
От | Tom Lane |
---|---|
Тема | Re: proposal: CREATE DATABASE vs. (partial) CHECKPOINT |
Дата | |
Msg-id | 18678.1414417601@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: proposal: CREATE DATABASE vs. (partial) CHECKPOINT (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: proposal: CREATE DATABASE vs. (partial) CHECKPOINT
Re: proposal: CREATE DATABASE vs. (partial) CHECKPOINT |
Список | pgsql-hackers |
Heikki Linnakangas <hlinnakangas@vmware.com> writes: > On 10/27/2014 03:21 PM, Tomas Vondra wrote: >> Thinking about this a bit more, do we really need a full checkpoint? That >> is a checkpoint of all the databases in the cluster? Why checkpointing the >> source database is not enough? > A full checkpoint ensures that you always begin recovery *after* the > DBASE_CREATE record. I.e. you never replay a DBASE_CREATE record during > crash recovery (except when you crash before the transaction commits, in > which case it doesn't matter if the new database's directory is borked). Yeah. After re-reading the 2005 thread, I wonder if we shouldn't just bite the bullet and redesign CREATE DATABASE as you suggest, ie, WAL-log all the copied files instead of doing a "cp -r"-equivalent directory copy. That would fix a number of existing replay hazards as well as making it safe to do what Tomas wants. In the small scale this would cause more I/O (2 copies of the template database's data) but in production situations we might well come out ahead by avoiding a forced checkpoint of the rest of the cluster. Also I guess we could skip WAL-logging if WAL archiving is off, similarly to the existing optimization for CREATE INDEX etc. regards, tom lane
В списке pgsql-hackers по дате отправления: