On Wed, Jun 1, 2016 at 10:48 PM, <timofeid@outlook.com> wrote:
> 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=D0=B5maker pgsql agent.
You surely want to update to 9.4.8 first. You are missing many bug fixes.
> Sometimes we have troubles with fsm-files. In case:
> =E2=80=A2 master instance is switching to another node(failover or switc=
hover) on
> highload
> =E2=80=A2 Hot standby node restart and run as master succesfully.
> =E2=80=A2 After that we sometimes get FSM files pointing to non-existent=
blocks in
> the table, so subsequent insert operations on such tables fails with erro=
r
> 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 s=
uch
> problems? Are there any recommendations on how to avoid them?
Andres, do you think that c6ff84b0 can help here? Those symptoms look
rather similar to some missing invalidation messages on the standby.
--=20
Michael