From: Robert Haas [mailto:robertmh...@gmail.com] > On Fri, Nov 18, 2016 at 4:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > >> Tom Lane wrote: > >>> IMO it's not, and closer analysis says that this patch series is an > >>> attempt to solve something we already fixed, better, in 9.4. > > > >> ... by the same patch submitter. > > > > [ confused ] The commit log credits 82233ce7e to MauMau and yourself. > > IIUC, MauMau = Tsunakawa Takayuki.
Yes, it's me. I'm pleased that you remember me! First, I understand that zapping the stats file during recovery can be a problem. In fact, it's me who proposed adding a sentence in the manual that the stats file is reset after immediate shutdown. I think addressing this problem is another topic in a new thread. The reasons why I proposed this patch are: * It happened in a highly mission-critical production system of a customer who uses 9.2. * 9.4's solution is not perfect, because it wastes 5 seconds anyway, which is unexpected for users. The customer's requirement includes failover within 30 seconds, so 5 seconds can be seen as a risk. Plus, I'm worried about the possibility that the SIGKILLed process wouldn't disappear if it's writing to a network storage like NFS. * And first of all, the immediate shutdown should shut the server down immediately without doing anything heavy, as the name means. So, I think this patch should also be applied to later releases. The purpose of the patch in 9.4 was to avoid PostgreSQL's bug, where the ereport() in quickdie() gets stuck waiting for malloc()'s lock to be released. Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
