"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
