"Florian G. Pflug" <fgp@phlo.org> writes:
> It might be even worse - I'm not sure that a rename is an atomic operation
> on most filesystems.
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?
And there's still the problem that changing the filename on-the-fly is
going to break tons of low-level stuff, most of which is not supposed to
know about transactions at all, notably bgwriter.
What I was thinking about was a "flag file" separate from the data file
itself, a bit like what we use for archiver signaling. If nnnn is the
new data file, then "touch nnnn.new" to mark the file as needing to be
deleted on restart. Remove these files just *before* commit. This
leaves you with a narrow window between removing the flag file and
actually committing, but there's no risk of having to PANIC --- if the
remove fails, you just abort the transaction.
However, this has nonzero overhead compared to the current behavior.
I'm still dubious that we have a problem that needs solving ...
regards, tom lane
