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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] 'pgsql/src/backend/parser gram.c'
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] pg_dump problem?