Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> I committed a patch to do a full-blown checkpoint before the copy.
> Annoying to do two checkpoints, but CREATE DATABASE is a pretty
> heavy-weight operation anyway. I don't see any other solution at the
> moment, at least not one that we could back-patch.
Agreed. Patch looks good.
I tried to reproduce the issue here using yesterday's CVS HEAD.
It is not hard to get the "file does not exist" failure, but so
far as I can tell CREATE DATABASE does clean up the target directory
before reporting that failure to the user. It is probably possible
to interrupt the cleanup, but if that happened then the original
error message wouldn't ever get delivered at all. So I'm mystified
how Matthew could have seen the expected error and yet had the
destination tree (or at least large chunks of it) left behind.
[ thinks for a bit... ] We know there were multiple occurrences.
Matthew, is it possible that you had other createdb failures that
did *not* report "file does not exist"? For instance, a createdb
interrupted by a "fast" database shutdown might have left things this
way.
regards, tom lane
