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, I
wouldlike 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.
Or, maybe we can just stop removing the stats files during recovery by keeping the files of previous generation and
usingit as the current one. I haven't seen how fresh the previous generation is (500ms ago?). A bit older might be
betterthan nothing.
> The larger picture here is that Takayuki-san wants us to commit a patch
> based on a customer's objection to 9.2's behavior, without any real evidence
> that the 9.4 change isn't a sufficient solution. I've got absolutely zero
> sympathy for that "the stats collector might be stuck in an unkillable state"
> argument --- where's the evidence that the stats collector is any more prone
> to that than any other postmaster child?
9.4 change may be sufficient. But I don't think I can proudly explain the logic to a really severe customer. I can't
answerthe question "Why does PostgreSQL write files that will be deleted, even during 'immediate' shutdown? Why does
PostgreSQLuse 5 seconds for nothing?"
Other children do nothing and exit immediately. I believe they are behaving correctly.
> And for that matter, if we are stuck because of a nonresponding NFS server,
> how is a quicker postmaster exit going to help anything?
> You're not going to be able to start a new postmaster if the data directory
> is on a nonresponsive server.
NFS server can also be configured for HA, and the new postmaster can start as soon as the NFS server completes
failover.
> I'd be willing to entertain a proposal to make the 5-second limit adjustable,
> but I don't think we need entirely new behavior here.
Then, I'm at a loss what to do for the 9.2 user.
Regards
Takayuki Tsunakawa