CREATE DATABASE vs delayed table unlink

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

Responses

Browse pgsql-hackers by date

  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