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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
