From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fd.c doesn't remove files on a crash-restart |
Date: | 2016-03-16 22:16:14 |
Message-ID: | 56E9DB2E.6060807@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/16/16 2:16 PM, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Mar 16, 2016 at 2:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-03-16 22:31:10 | Re: Using quicksort for every external sort run |
Previous Message | Mark Dilger | 2016-03-16 22:01:51 | Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check |