Claudio Natoli <claudio.natoli@memetrics.com> writes:
> Tom Lane wrote:
>> However, I don't see exactly how that can win?
> Why not?
More like "why?". The problem we have is with making sure that existing
files we don't want anymore will go away in a timely fashion. I don't
see how it helps to modify file creation to allow overwrite. We are not
(in most deletion cases) expecting anyone to re-create that file later.
Moreover, allowing overwrite when the code isn't otherwise expecting
it takes away a fairly significant error check, namely that we don't
accidentally assign the same relfilenode to two different relations.
At the moment I think that failure during open() is our *only* line
of defense against relfilenode collision. Even if we were willing
to add the overhead of an otherwise-useless unique index on
pg_class.relfilenode, I'd not really want to give up the open() check.
Stomping on someone else's file is just too disastrous...
AFAIR the only case where we're really deleting files with the intention
of replacing them shortly is in the code paths that initially write a
temp file and then rename it into place. Open-with-overwrite is no help
there anyway, because it would mean giving up the existing defenses
against readers seeing inconsistent intermediate states of the file.
So unless I'm totally misunderstanding where you mean to use this code,
I don't see the point.
regards, tom lane
