The error on createdb happened again this morning. However, this time an
abandoned directory was not created. The full error message was:
$ createdb -E SQL_ASCII -U flyminebuild -h brian.flymine.org -T
production-flyminebuild production-flyminebuild:uniprot
createdb: database creation failed:
Matthew Wakeling <[EMAIL PROTECTED]> writes:
> On Thu, 9 Oct 2008, Tom Lane wrote:
>> 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.
> Remember I was running 8.3.0, and you mentioned a few changes
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Another thought is to ignore ENOENT in copydir.
On Wed, 8 Oct 2008, Tom Lane wrote:
Yeah, I thought about that too, but it seems extremely dangerous ...
I agree. If a file randomly goes missing, that's not an error to ignore,
even if you think
On Thu, 9 Oct 2008, Tom Lane wrote:
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.
Remember I was running 8.3.0, and you mentioned a few changes after that
version which would have made sure the des
Heikki Linnakangas <[EMAIL PROTECTED]> 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 ba
Matthew Wakeling wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Another thought is to ignore ENOENT in copydir.
On Wed, 8 Oct 2008, Tom Lane wrote:
Yeah, I thought about that too, but it seems extremely dangerous ...
I agree. If a file randomly goes missing, that's not an error to ig
Matthew Wakeling wrote:
I could be wrong - but couldn't other bad things happen too? If you're
copying the files before the checkpoint has completed, couldn't the new
database end up with some of the recent changes going missing? Or is
that prevented by FlushDatabaseBuffers?
FlushDatabaseBuff
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Another thought is to ignore ENOENT in copydir.
Yeah, I thought about that too, but it seems extremely dangerous ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
Tom Lane wrote:
The thread here
http://archives.postgresql.org/pgsql-performance/2008-10/msg00031.php
illustrates an undesirable side effect of the recent patch to delay
table file unlinks to the next checkpoint. What is evidently happening
is that copydir() fetches a block of a directory, and b
The thread here
http://archives.postgresql.org/pgsql-performance/2008-10/msg00031.php
illustrates an undesirable side effect of the recent patch to delay
table file unlinks to the next checkpoint. What is evidently happening
is that copydir() fetches a block of a directory, and by the time it
arri
10 matches
Mail list logo
