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" 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

Reply via email to