Tom Lane wrote:
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
Maybe just get back to the beginning:
We are concerned about leaking files on *crashes*.
So during recovery, the only time we are going to care, iterate through
list of files that should exist (pg_class) after replay of log.
Any files that don't belong (but fit the standard naming conventions)
move to spclocation/trash or similar.
For the admin who had critical data they needed to recover and is going
to spend the time going to the disk too pull it out they still can
access it. This also saves admins who create table like filenames in
table spaces.
For most other folks they can dump /trash.
Does this avoid the dataloss worries?
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
