From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Tomas Vondra <tv(at)fuzzy(dot)cz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: CREATE DATABASE vs. (partial) CHECKPOINT |
Date: | 2014-10-27 13:46:41 |
Message-ID: | 18678.1414417601@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-10-27 13:51:41 | Re: proposal: CREATE DATABASE vs. (partial) CHECKPOINT |
Previous Message | Andres Freund | 2014-10-27 13:32:18 | Lockless StrategyGetBuffer() clock sweep |