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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
