Re: BUG #14171: Wrong FSM file after switching hot standby to master
От | Michael Paquier |
---|---|
Тема | Re: BUG #14171: Wrong FSM file after switching hot standby to master |
Дата | |
Msg-id | CAB7nPqRGbous8bpLRskypXLpFJdte-Psjz_PbV51OQnSaiNBjQ@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #14171: Wrong FSM file after switching hot standby to master (timofeid@outlook.com) |
Список | 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 по дате отправления: