"Florian G. Pflug" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> rename(2) is specified to be atomic by POSIX, but relinking a file into >> a different directory can hardly be --- it's not even provided as a >> single kernel call, is it?
> I'd have thought that they only guarantee that if the new name already > exists it's atomically replaced. But I might be wrong.... I reread the spec and realized that rename() does include moving a link into a different directory --- but it only promises that replacement of the target filename is atomic, not that (say) the link couldn't appear in both directories concurrently. Also it's not clear that the spec intends to make any hard guarantees about the filesystem state after crash-and-recovery. In any case I don't think we can make renaming of active data files work --- bufmgr and bgwriter need those file names to be stable. The flag-file approach seems more promising. There's also the plan B of scanning pg_class to decide which relfilenode values are legit. IIRC Bruce did up a patch for this about a year ago, which I vetoed because I was afraid of the consequences if it removed data that someone really needed. Someone just mentioned doing the same thing but pushing the unreferenced files into a "trash" directory instead of actually deleting them. While that answers the risk-of-data-loss objection, I'm not sure it does much for the goal of avoiding useless space consumption: how many DBAs will faithfully examine and clean out that trash directory? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate