Re: [HACKERS] Re: Nasty resource-leak problem in sort code - Mailing list pgsql-hackers

From geek+@cmu.edu
Subject Re: [HACKERS] Re: Nasty resource-leak problem in sort code
Date
Msg-id emacs-smtp-6098-14131-4696-691968@export.andrew.cmu.edu
Whole thread Raw
In response to Re: Nasty resource-leak problem in sort code  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Re: Nasty resource-leak problem in sort code
Re: [HACKERS] Re: Nasty resource-leak problem in sort code]
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Nasty resource-leak problem in sort code
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] 'pgsql/src/backend/parser gram.c'