August Zajonc wrote:
I assume that you meant that mail to go to pgsql-hackers too, and just
clicked the wrong button by accident. If not, please forgive that
I post the reply to the list.
> Are you going to look at putting temp relations into a special folder
> for 8.4? I really like that idea for crash cleanup and generally.
According to Alvaro, that is already the case. I didn't check, though.
> For non temp files, can they be created in a pending folder, work done
> on them, and then moved over to final destination just before commit?
Hm... that doesn't sound bad at first sight. We'd need one such folder
per tablespace, though.
> You could still leak them (ie, you move to final location and bail
> before commit) but it seems to narrow the window down significantly.
That leak could be prevented I think if the COMMIT record indicated
which files are to be moved, and the actual move happens after the
flushing the COMMIT record to disk. Probably the move would need to
happen while we're in the commit critical section too, to guard
against concurrent checkpoints - but that all seems doable.
> Actually, as I write this, a bad idea, the temp files are the low
> hanging fruit, don't think it's worth dealing with non-temp files until
> you can make it totally leakproof.
There is no fundamental difference between temporary and non-temporary
delete-on-abort files I think. There is one for delete-on-commit files,
(and only because of asynchronous commits)
but the leakage possibility for those is already really small (I'd
take a COMMIT, a crash *and* a CHECKPOINT at just the right time to
get a leak).
The hardest part seems to be making the code cope with moved files.
Though we only need to care about that local backend I believe, because
all others haven't yet seen the files anyway.
greetings, Florian Pflug