From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Subject: | Re: File leak? |
Date: | 2004-06-13 19:27:21 |
Message-ID: | 2070.1087154841@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On Sat, 12 Jun 2004, Tom Lane wrote:
>> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>>> I wonder if we could clean up those lost files on database recovery or
>>> vacuum.
>>
>> There is a TODO for this, but it seems exceedingly low priority to me.
> Are you sure? I read through the TODO list but couldn't find it.
Well, there used to be: 7.4 TODO has
* Remove unreferenced table files and temp tables during database vacuum
or postmaster startup (Bruce)
Now that I think about it, I believe Bruce recently removed this on my
advice; I was thinking that the problem shouldn't occur anymore now that
we WAL-log file creation and deletion. But actually the present form of
the WAL entries doesn't ensure that a file created by a transaction that
crashes before committing will go away, because file deletion actions
are only logged (and replayed) at transaction commit/abort. So it
probably should go back in. Or else we could add more WAL logging
(viz, log at the instant of file creation, and the replayer would have
to keep track of whether it sees the creating transaction commit and
delete the file if not).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Cave-Ayland | 2004-06-13 21:23:10 | Can get GiST RECHECK clause to work |
Previous Message | Heikki Linnakangas | 2004-06-13 19:01:19 | Re: File leak? |