From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | timofeid(at)outlook(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14171: Wrong FSM file after switching hot standby to master |
Date: | 2016-06-02 14:42:32 |
Message-ID: | 20160602144232.33gyusj2dekzk7cp@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2016-06-02 16:42:35 +0900, Michael Paquier wrote:
> > 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?
>
> Andres, do you think that c6ff84b0 can help here? Those symptoms look
> rather similar to some missing invalidation messages on the standby.
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?
Regards,
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2016-06-02 17:36:41 | Re: BUG #14169: Incorrect merge join result in 9.5 |
Previous Message | lony.namer | 2016-06-02 12:32:14 | BUG #14172: RPM repository for i386 not working, repomd.xml file is missing. |