BUG #14171: Wrong FSM file after switching hot standby to master

The following bug has been logged on the website:

Bug reference: 14171
Logged by: Timofei Dynikov
Email address: timofeid(at)outlook(dot)com
PostgreSQL version: 9.4.4
Operating system: RHEL 6.6
Description:

Hi

We have an installation of Postgres 9.4.4(PostgreSQL 9.4.4 on
x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat
4.4.7-11), 64-bit) on RHEL 6.6. DB installed on 2 nodes, 1 node is master,
another node is hot standby(streaming replication). DB is monitored by
pacеmaker pgsql agent.
Sometimes we have troubles with fsm-files. In case:
• master instance is switching to another node(failover or switchover) on
highload
• Hot standby node restart and run as master succesfully.
• After that we sometimes get FSM files pointing to non-existent blocks in
the table, so subsequent insert operations on such tables fails with error
message like following: 'could not read block XX in file "base/YYYY/ZZZZZ"'.
The issue can be resolved by either deleting of wrong FSM file (while
database is stopped) or performing VACUUM FULL on erroneous table. The
problem is usually observed on relatively small tables (e.g. up to 30
blocks) which are often cleaned out (having most rows deleted).
Does anybody already faced such behavior? What can be the root cause of such
problems? Are there any recommendations on how to avoid them?