I wrote:
> It seems our choices are (a) somehow fix things so CREATE DATABASE
> replay doesn't have to zap the whole directory, (b) force a checkpoint
> immediately after any CREATE DATABASE, so that we never have to replay
> one except in a PITR situation, or (c) abandon non-WAL-logged index
> and table builds.
Having overcome my initial dismay at missing such a fundamental problem,
I've thought harder about it and concluded that (b) is clearly the thing
to do.
I think it would take a wholesale redesign of the CREATE DATABASE
mechanism to do (a). While there are a number of ugly things about
CREATE DATABASE that could perhaps be fixed with a redesign,
I don't currently have any good idea about how to do it right.
In any case this path wouldn't be an acceptable backpatch for the 8.0
branch.
(c) is clearly not the direction we really wish to take, either.
Also, I realized that there is an entirely independent problem that (b)
will protect us against. Consider this scenario:
create database acopy;\c template1create table bozo(f1 int);-- now system crashes and replays WAL
After this sequence it is possible for "acopy" to contain the table
"bozo", because the replay of the CREATE DATABASE will copy whatever
is on disk in template1. (You can actually duplicate this in 8.0
and HEAD, if you wait long enough for the bgwriter to write the
catalog changes, but not long enough for a checkpoint to happen.)
Accordingly, I've committed (b) into 8.0 and HEAD. (Earlier branches
are not at risk because they didn't WAL-log CREATE DATABASE at all.)
This might be sufficient reason to release an 8.0.4 pretty soon.
regards, tom lane