From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Cc: | Matthew Wakeling <matthew(at)flymine(dot)org>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Subject: | CREATE DATABASE vs delayed table unlink |
Date: | 2008-10-08 16:08:55 |
Message-ID: | 10977.1223482135@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-10-08 16:13:02 | Re: autovacuum and reloptions |
Previous Message | Gregory Stark | 2008-10-08 16:08:22 | Re: autovacuum and reloptions |