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

From: Timofei Dynikov <timofeid(at)outlook(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: 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-03 10:09:11
Message-ID: DUB126-W5D9CC621EEEADCDB743D1CD590@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> Date: Thu, 2 Jun 2016 07:42:32 -0700
> From: andres(at)anarazel(dot)de
> To: michael(dot)paquier(at)gmail(dot)com
> CC: timofeid(at)outlook(dot)com; pgsql-bugs(at)postgresql(dot)org
> Subject: Re: [BUGS] BUG #14171: Wrong FSM file after switching hot standby to master
>
> 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

Yes, problem persists across restarts. We can resolve problem only by performing VACUUM FULL or delete inconsistent FSM file.

Regards,Timofei Dynikov

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message furstenheim 2016-06-03 10:37:44 BUG #14173: Not using partitions with ANY(ARRAY[...])
Previous Message Michael Paquier 2016-06-03 06:17:57 Re: [BUGS] BUG #14155: bloom index error with unlogged table