Re: Error handling (or lack of it) in RemovePgTempFilesInDir - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Error handling (or lack of it) in RemovePgTempFilesInDir
Date
Msg-id CAB7nPqRGpkpJp2UkxU04br+Ya3C+Hea0E1ocnjiLFHMaOF4zkw@mail.gmail.com
Whole thread Raw
In response to Re: Error handling (or lack of it) in RemovePgTempFilesInDir  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Error handling (or lack of it) in RemovePgTempFilesInDir
List pgsql-hackers
On Tue, Dec 5, 2017 at 11:15 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Tue, Dec 5, 2017 at 10:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Uh ... I'm confused?  That particular change only concerns whether we emit
>>> a log message, not whether the action is attempted or succeeds.
>
>> From the commit mentioned upthread, this switches one hard failure
>> when opening pg_tblspc to a LOG report:
>> @@ -3014,7 +3018,7 @@ RemovePgTempFiles(void)
>>      */
>>     spc_dir = AllocateDir("pg_tblspc");
>
>> -   while ((spc_de = ReadDir(spc_dir, "pg_tblspc")) != NULL)
>> +   while ((spc_de = ReadDirExtended(spc_dir, "pg_tblspc", LOG)) != NULL)
>>     {
>
> That's not the same commit you just mentioned.

561885db05d3296082ce8750805b8ec322cf9aa1 refers to this thread, and I
am reading this diff as part of it :)

> The general theory I'm operating on is that we should endeavor to
> let the database start in any situation where that doesn't involve
> a data-corruption hazard.  Yeah, it might not be nice if we leave
> GB worth of temp files around, but is a postmaster start failure
> better?  I don't think so.

I am getting the feeling that we are going to see people complain
about those files lying around as well... That's as far as my opinion
goes.
-- 
Michael


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error handling (or lack of it) in RemovePgTempFilesInDir
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] pow support for pgbench