On Wed, 8 Oct 2008, Tom Lane wrote:
> Hmm, would that include dropping tables in the database you are about to
> copy? If so, this error is fairly readily explainable as a side effect
> of the delayed dropping of physical files in recent PG versions.
It could quite possibly include dropping tables. We're running quite a
complex system with lots going on all the time.
> (As noted in the manual, CREATE DATABASE isn't really intended as a COPY
> DATABASE operation --- it is expecting the source database to be pretty
> static. I think you could make this more reliable if you do a manual
> checkpoint between modifying the source database and copying it.)
I gather this. However, I think it would be sensible to make sure it can
never "corrupt the database" as it were. It's fine for it to lock everyone
out of the database while the copying is happening though. The only reason
for it to fail should be if someone is logged into the template database.
> Do you have some specific examples of this error message at hand?
> Can you try to confirm whether the reported path corresponds to
> something in the CREATE's source database? If it's actually
> complaining about a stat failure in the target tree, then there's
> something else going on altogether. I don't see anything in that
> path that would give this message, but I might be missing it.
The oid in the error message is of a database that no longer exists, which
indicates that it is *probably* referring to the template database.
Unfortunately my colleagues just wrote the script so that it retries, so
we don't have a decent log of the failures, which were a while back.
However, I have now altered the script so that it fails with a message
saying "Report this to Matthew", so if it happens again I'll be able to
give you some more detail.
Matthew
--
You will see this is a 3-blackboard lecture. This is the closest you are going
to get from me to high-tech teaching aids. Hey, if they put nooses on this, it
would be fun! -- Computer Science Lecturer