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

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

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] 'pgsql/src/backend/parser gram.c'
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] pg_dump problem?