 
> Yes, that is true.  As long as the storage manager relies on 
> the filesystem for
> table names, this will be a problem, unless filesystem 
> deletions are delayed
> until COMMIT, and filesystem creates are undone at a ROLLBACK.

I like Bruce's idea of altering the filename from tablename_segnr 
to tablename_OID_segnr.
Then a leftover new or old file will not be a problem, since it has a 
guaranteed different name. 
The cleanup of leftover old (or rolled back new files) could then be 
a job that vacuum does.

Vadim needs _oid_ in the filenames for WAL anyway.

This solves create and drop table.

The alter table should imho keep an exclusive lock on the 
pg_class row for that table + exclusive on the usertable
until transaction commit. 
(Thus fails if table access is not exclusive)

Andreas

Wed, 1 Dec 1999 11:20:39 +0100 
Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions