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