| 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 |
| Subject: | Re: File leak? |
| Date: | 2004-06-14 12:42:46 |
| Message-ID: | 26133.1087216966@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> I'm afraid that's not enough. Checkpoints spoil it, think:
> 1. CREATE TABLE foobar ...
> 2. INSERT ....
> 3. <checkpoint>
> 4. <crash>
> The replay would not see the file-creation WAL record.
Good point. That makes it messy enough that we probably don't want to
do it that way. Scan-for-unreferenced-files is looking a lot more
robust (although it has its own interesting race-condition issues if
you try to do it in a live system).
>> I'm not sure what the performance implications of this would be; it's
>> likely that pushing the cost somewhere else would be better.
> I don't think that file creation is that common for it to matter..
Maybe not for regular tables, but for temp tables I'm less convinced.
If we could do the unreferenced-file scan only at completion of a crash
recovery then it'd be zero cost in all normal paths ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-06-14 12:52:14 | Re: Releasing 7.4.3 ... |
| Previous Message | Tom Lane | 2004-06-14 12:15:45 | Re: Releasing 7.4.3 ... |