Re: fd.c doesn't remove files on a crash-restart - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: fd.c doesn't remove files on a crash-restart
Date
Msg-id 56E9DB2E.6060807@BlueTreble.com
Whole thread Raw
In response to Re: fd.c doesn't remove files on a crash-restart  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 3/16/16 2:16 PM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Mar 16, 2016 at 2:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Possible compromise: remove files only in non-Assert builds?
>
>> That sorta seems like tying two things together that aren't obviously
>> related.  I think building with --enable-cassert is support to enable
>> debugging cross-checks, not change behavior.
>
> Well, it's support to enable debugging, and I would classify not
> destroying evidence as being debugging support.

Another option: keep stuff around for a single restart. I don't think 
this would be that hard by having a file that's a list of files to 
remove on the next restart. On restart, remove everything in that file 
(and the file itself). If there's anything left, create a new file 
that's the list of what's left.

The other nice thing about having this list is it would tell the DBA 
exactly what files were left after the crash vs what's new.

Actually, I guess another option would be to have a separate directory 
to move all these files into. On restart, nuke the directory if it 
exists, then move stuff in there if necessary.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
Next
From: Robert Haas
Date:
Subject: Re: Using quicksort for every external sort run