Re: BUG #14171: Wrong FSM file after switching hot standby to master - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #14171: Wrong FSM file after switching hot standby to master
Date
Msg-id CAB7nPqRGbous8bpLRskypXLpFJdte-Psjz_PbV51OQnSaiNBjQ@mail.gmail.com
Whole thread Raw
In response to BUG #14171: Wrong FSM file after switching hot standby to master  (timofeid@outlook.com)
List pgsql-bugs
On Fri, Jun 3, 2016 at 7:09 PM, Timofei Dynikov <timofeid@outlook.com> wrote:
>> Date: Thu, 2 Jun 2016 07:42:32 -0700 andres@anarazel.de wrote:
>> If there was a restart involved, it seems unlikely that that'll be
>> relevant. Timofei, do I understand correctly that the problem persists
>> across restarts?
>
> Yes, problem persists across restarts. We can resolve problem only by
> performing VACUUM FULL or delete inconsistent FSM file.

pacemaker removes recovery.conf and then restarts the node at
failover, so the node moves on with a crash recovery on the same
timeline in this case. I recall seeing cases where a relation file was
truncated when crash recovery began in 9.4.4, that got fixed in 9.4.5.
The environment where this happened made it hard to compile to
reproduce it but I somewhat diagnosed this as being a side effect of
be25a08, that e118555 fixed afterwards, at least I did not see
anything else that could have been the origin of the problem between
9.4.4 and 9.4.5. The problem was in the same way happening on a small
table, one that had no more than 5 tuples, and those were removed
quite frequently to the table was most of the time empty, however when
crash recovery began it had some records.

Could you update to at least 9.4.5 and see if the problem goes away?
We may as well have another problem hidden here..
--
Michael

pgsql-bugs by date:

Previous
From: andrew@tao11.riddles.org.uk
Date:
Subject: BUG #14174: Expanded-datum bug accessing freed memory
Next
From: Timofei Dynikov
Date:
Subject: Re: BUG #14171: Wrong FSM file after switching hot standby to master