Re: [HACKERS] Re: Nasty resource-leak problem in sort code

Поиск
Список
Период
Сортировка
От geek+@cmu.edu
Тема Re: [HACKERS] Re: Nasty resource-leak problem in sort code
Дата
Msg-id emacs-smtp-6098-14131-4696-691968@export.andrew.cmu.edu
обсуждение исходный текст
Ответ на Re: Nasty resource-leak problem in sort code  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Re: Nasty resource-leak problem in sort code  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Re: Nasty resource-leak problem in sort code]  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
Then <tgl@sss.pgh.pa.us> spoke up and said:
> After further thought it seems that adding code to release temporary
> files at transaction abort is the best solution.  I propose the
> following fix:
[ explanation snipped ]

Uhm, this all seems unnecessarily complicated.  Shouldn't the process
look more like this:
fp = open('tempfile');
unlink('tempfile');

This way, when the file is closed, the space is freed.  The only
complication I can see is if backends need to share the file handle,
or it needs to be re-opened.  This works with all sorts of temp-file
situations.

Of course, it's not NT safe, since I don't believe that NT provides
for deleting open files (NT file libs sucks.

-- 
=====================================================================
| JAVA must have been developed in the wilds of West Virginia.      |
| After all, why else would it support only single inheritance??    |
=====================================================================
| Finger geek@cmu.edu for my public key.                            |
=====================================================================

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Nasty resource-leak problem in sort code
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] 'pgsql/src/backend/parser gram.c'