Re: fd.c doesn't remove files on a crash-restart

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 19:14:02
Message-ID: CA+TgmoZwGNFnng25xkJbqfkiaaKcnks6s7rBPKo_gM9HZqwqjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 16, 2016 at 2:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>> Hello,
>> fd.c[1] will remove files from pgsql_tmp on a restart but not a
>> crash-restart per this comment:
>
>> /*
>> * NOTE: we could, but don't, call this during a post-backend-crash restart
>> * cycle. The argument for not doing it is that someone might want to
>> examine
>> * the temp files for debugging purposes. This does however mean that
>> * OpenTemporaryFile had better allow for collision with an existing temp
>> * file name.
>> */
>
>> I understand that this is designed this way. I think it is a bad idea
>> because:
>
> 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.

I would vote for removing them always, and if somebody doesn't want to
remove them, well then they can comment the code out.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-03-16 19:16:30 Re: fd.c doesn't remove files on a crash-restart
Previous Message Robert Haas 2016-03-16 19:08:07 Re: Performance degradation in commit ac1d794