Simon Riggs <simon@2ndquadrant.com> writes:
> On Tue, 2005-03-22 at 21:42 -0500, Bruce Momjian wrote:
>> Is this a TODO?
> Yes, it is.
> In my experience, most people create only a single Database, then define
> their Tablespaces (or change them rarely, if ever). So I've always
> regarded CREATE DATABASE and TABLESPACE as lower priority items. I'd
> always recommend taking another full backup immediately following such
> changes, rather than rely on everything working in the rollforward. That
> was true with PITR and similarly true with log shipping based upon PITR.
In the post-initlocation world, I think CREATE/DROP DATABASE are no big
problems. The bug Oleg encountered was really just a thinko or
premature optimization on my part: these operations should log database
and tablespace OIDs and let the recovery process recompute directory
pathnames from those, but I had stupidly made them log absolute paths
instead.
There may still be some race-condition-type risks associated with CREATE
DATABASE but I don't think they are any worse for WAL replay than they
are for normal operation. You just can't safely modify a DB that is an
active CREATE DATABASE template.
DROP TABLESPACE isn't a problem either; we were already logging just the
tablespace OID, so that should work fine.
The hard part is CREATE TABLESPACE, and the reason it's hard is that
someone might possibly want the tablespace to be located at a different
place on the recipient machine than it is on the master. I do not see a
reasonable way to support that at the moment. For the moment I think we
should just document that as a gotcha, and make a TODO item to find a
way to do it.
regards, tom lane
