From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Matthew Wakeling <mnw21(at)cam(dot)ac(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CREATE DATABASE vs delayed table unlink |
Date: | 2008-10-09 12:37:41 |
Message-ID: | 12975.1223555861@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-10-09 12:40:42 | Re: WITH RECURSIVE ... simplified syntax? |
Previous Message | ITAGAKI Takahiro | 2008-10-09 12:01:10 | Re: [WIP] Reduce alignment requirements on 64-bit systems. |