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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: geek+(at)cmu(dot)edu
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: Nasty resource-leak problem in sort code
Date: 1999-05-07 18:08:03
Message-ID: 13711.926100483@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

geek+(at)cmu(dot)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

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-05-07 21:16:58 Re: [HACKERS] pg_dump problem?
Previous Message Tom Lane 1999-05-07 16:22:27 Re: [COMMITTERS] 'pgsql/src/backend/parser gram.c'