Re: BUG #14171: Wrong FSM file after switching hot standby to master
От | Andres Freund |
---|---|
Тема | Re: BUG #14171: Wrong FSM file after switching hot standby to master |
Дата | |
Msg-id | 20160602144232.33gyusj2dekzk7cp@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #14171: Wrong FSM file after switching hot standby to master (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: BUG #14171: Wrong FSM file after switching hot standby
to master
|
Список | 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
В списке pgsql-bugs по дате отправления: