Re: Why copy_relation_data only use wal whenWALarchivingis enabled

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