Heikki Linnakangas wrote: > Tom Lane wrote: >> I tend to agree that truncating the file, and extending the fsync >> request mechanism to actually delete it after the next checkpoint, >> is the most reasonable route to a fix. > > Ok, I'll write a patch to do that.
There's a small problem with that: DROP TABLESPACE checks that the tablespace directory is empty, and fails if it sees one of those empty files. You also run into that problem if you 1. BEGIN; CREATE TABLE; -- no commit 2. crash+restart 3. DROP TABLESPACE because we leave behind the stale file created by CREATE TABLE. The best I can think of is to rename the obsolete file to <relfilenode>.stale, when it's scheduled for deletion at next checkpoint, and check for .stale-suffixed files in GetNewRelFileNode, and delete them immediately in DropTableSpace. That still won't fix the problem with files created by a crashed transaction. For that we had a plan a long time ago: after recovery, scan the data directory for any files don't have a live row in pg_class, and write a message to log for each so that the DBA can delete them (deleting them automatically was considered too dangerous). That's probably 8.4 material, though. Thoughts? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
