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?