Re: [HACKERS] Re: Nasty resource-leak problem in sort code
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: Nasty resource-leak problem in sort code |
Дата | |
Msg-id | 13711.926100483@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Nasty resource-leak problem in sort code (geek+@cmu.edu) |
Список | pgsql-hackers |
geek+@cmu.edu writes: > Uhm, this all seems unnecessarily complicated. Shouldn't the process > look more like this: > fp = open('tempfile'); > unlink('tempfile'); I did think of that, but it only solves the problem of making sure the temp file goes away when you close it; it doesn't solve the problem of making sure that you close it. It's failure to release the file descriptors that is causing backend crashes --- waste of diskspace is bad also, but it's not the critical issue IMHO. We *must* add cleanup code to ensure that the FDs are closed after an abort; once we do that it's essentially no extra code to unlink the files at the same time. Doing the unlink right away would ensure that the temp file disappears if the backend crashes before it gets to transaction commit/abort. However, I regard that as a bad thing not a good thing, because it would complicate debugging --- you might want to be able to see what had been in the temp files. You normally have to clean up a core file to recover diskspace after a backend crash, so having to delete temp files too doesn't seem like a big shortcoming. > Of course, it's not NT safe, since I don't believe that NT provides > for deleting open files (NT file libs sucks. Don't think it works over NFS mounts, either. regards, tom lane
В списке pgsql-hackers по дате отправления: