Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Tom Lane wrote:
>>> +1 on the first, but -1 on the second, because we'd have to track
>>> whether deleted files are temp or not ... it's very unclear that it'd
>>> be worth the trouble.
>
>> I'm confused. smgrcreate already tracks if it created a file for a temp
>> relation or not (at least it has an isTemp parameter, which it also
>> stores in the delete list).
>
> Doh, I was thinking it did not track that --- serves me right for not
> checking the code before opining.
So should we not force synchronous commit if all to-be-deleted files
are temporary? Or is that pushing our luck too much, because it opens
the window of possible file leakage considerably wider?
I don't have a strong preference - it seems to be low-hanging fruit
performance-wise - but then, maybe that fruit should be left hanging
until a time where we have some way of removing unreferenced files...
Thoughts, anyone?
>>> No, because the way you know the name is good is a successful
>>> open(O_CREAT).
>
>> The idea was to log *twice*. Once the we're about to create a file, and
>> the second time that we succeeded. That way, the filename shows up in the
>> log, even if we crash immediatly after physically creating the file, which
>> gives recovery at least a chance to clean up the mess.
>
> Hmm. Seems like a lot of work for something that's not a large problem.
> Anyway, I'd counsel not thinking about that for now, but keep the patch
> focused on solving one problem.
Don't worry, I won't be doing anything like that in this patch ;-) But since
my work on the patch made me thing about these things, I thought I'd share
my ideas...
greetings, Florian Pflug
