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 by the time it
> arrives at some particular entry in the block, a checkpoint has happened
> and that file got removed. If there are some large files in the
> directory then the window for this race condition can be wide.
>
> The only real solution I can see is to replace createdb()'s
> FlushDatabaseBuffers call with a full-blown checkpoint. It's pretty
> annoying to do *two* checkpoints in a CREATE DATABASE, but as long as
> we're doing this via filesystem-based APIs we probably haven't got much
> choice.
Hmph, that is pretty annoying. An extra checkpoint seems like the easy
solution.
Another thought is to ignore ENOENT in copydir. But then you'd still
copy all the lingering empty files, which would never be deleted. They'd
be zero-length, and you can end up with orphaned files anyway in crash
scenarios, but it'd still be annoying.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
