Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

On Mon, Apr 25, 2016 at 2:10 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Afaics the problem described below was introduced in b4e07417, do you
> have a different/better proposal than
> s/CacheInvalidateSmgr/CacheInvalidateRelcache/? Doing that doesn't feel
> quite right either, because it only makes the file extension visible at
> end-of-xact - which is mostly harmless, but still.

Maybe I'm all wet here, but it seems to me like this is a bug in
heap_xlog_visible(). If the relation has been extended on the master
but no bits are set, then it doesn't really matter whether any
invalidation happens on the standby. On the other hand, if the
relation has been extended on the master and a bit has actually been
set on the new page, then there should be an XLOG_HEAP2_VISIBLE record
that gets replayed on the standby. And replay of that record should
call visibilitymap_pin(), which should call vm_readbuf(), which should
call vm_extend(), which should issue the same smgr invalidation on the
standby that got issued on the master. So no problem! However, in
the FPI case, heap_xlog_visible() optimizes all of that away, so the
invalidation doesn't get issued. Oops. But we could cure that just
by having heap_xlog_visible() still call CacheInvalidateSmgr() even in
that case, and then we'd be actually be following the rule that
non-transactional invalidations should be issued on the standby even
while in replay. That seems cleaner to me than switching to a
transactional invalidation, which isn't really the right thing anyway.

In other words, I think Masahiko Sawada's patch in the original post
is pretty much right on target, except that we don't need to do that
always, but rather only in the FPI case when the call to
visibilitymap_pin() is being optimized away. If we solve the problem
that way, I don't think we even need a new WAL record for this case,
which is a non-trivial fringe benefit.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company