Re: [RFC] Should we fix postmaster to avoid slow shutdown?

On Tue, Nov 22, 2016 at 12:26 PM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>> The point I was trying to make is that I think the forced-removal behavior
>> is not desirable, and therefore committing a patch that makes it be graven
>> in stone is not desirable either.
>
> I totally agree that we should pursue the direction for escaping from the complete loss of stats files.  Personally,
Iwould like to combine that with the idea of persistent performance diagnosis information for long-term analysis (IIRC,
someoneproposed it.)  However, I don't think my patch will make everyone forget about the problem of stats file loss
duringrecovery.  The problem exists with or without my patch, and my patch doesn't have the power to delute the
importanceof the problem.  If you are worried about memory, we can add an entry for the problem in TODO list that
Bruce-sanis maintaining. 

I don't think Tom is worried about forgetting this. I think he is
worried that if we do the changes as suggested in 01... patch, we will
make it more difficult to change stats file behaviour later. Right now
we are throwing away statistics files at the time of crash recovery.
In case we want to change it tomorrow, we will have to fix the
existing problem with the half-written/stale stats files and then fix
not to zap those files at the time of crash recovery. In case we go
ahead with this patch, we will have more instances of creating
half-written/stale stats file, which will need to fixed.

>
> 9.4 change may be sufficient.  But I don't think I can proudly explain the logic to a really severe customer.  I
can'tanswer the question "Why does PostgreSQL write files that will be deleted, even during 'immediate' shutdown?  Why
doesPostgreSQL use 5 seconds for nothing?" 
>
> Other children do nothing and exit immediately.  I believe they are behaving correctly.

I agree, with this though.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company