On Mon, Apr 25, 2016 at 2:10 PM, Andres Freund <and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
