Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
Date
Msg-id 20160414015820.znc5sivkpjec7wzy@alap3.anarazel.de
Whole thread Raw
In response to Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.  (Noah Misch <noah@leadboat.com>)
Responses Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2016-03-31 01:02:06 -0400, Noah Misch wrote:
> On Thu, Mar 10, 2016 at 01:04:11AM +0900, Masahiko Sawada wrote:
> > As a result of looked into code around the recvoery, ISTM that the
> > cause is related to relation cache clear.
> > In heap_xlog_visible, if the standby server receives WAL record then
> > relation cache is eventually cleared in vm_extend,  but If standby
> > server receives FPI then relation cache would not be cleared.
> > For example, after I applied attached patch to HEAD, (it might not be
> > right way but) this problem seems to be resolved.
> > 
> > Is this a bug? or not?
> 
> It's a bug.

I agree it's a bug. If I understand correctly it's not really
visibilitymap related though:

Debugging shows that vm_extend() (on the master) correctly issues a
CacheInvalidateSmgr(), which ought to clear the smgr state on the
standby. But replay doesn't do anything like that.  That kind of sounded
familiar.  The issue is that vacuum doesn't assign an xid and thus
RecordTransactionCommit() doesn't emit a commit record, which in turn
means invalidation messages aren't sent to the standby.

Ugh.

We've recently discussed a very similar issue around
http://www.postgresql.org/message-id/20160227002958.peftvmcx4dxwe244@alap3.anarazel.de

Unfortunately Simon over in that thread disagreed there about fixing
this by always emitting a commit record when nmsgs > 0 in
RecordTransactionCommit().  I think this thread is a pretty strong hint
that we actually should do so.

- Andres



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Optimization for updating foreign tables in Postgres FDW
Next
From: Fujii Masao
Date:
Subject: Re: documentation build bleat