Re: Summary and Plan for Hot Standby

Greg Stark wrote:
> From discussions in the bar it sounds like this was actually a false
> start however as the RecentGlobalXmin in the backend doing the split
> could be less aggressive than the RecentGlobalXmin used by some other
> backend to hit the hint bits leading to inconsistent results :(

Yeah, RecentGlobalXmin was wrong, it's not used at the moment.

> I'm leaning towards having the backend actually go fetch all the
> xmin/xmaxes of the pointers being pruned. It ought to be possible to
> skip that check in any database with no live snapshots so recovery
> performance would be unaffected on replicas not actively being used in
> hot mode.

Hmm, I have always been thinking that it would be detrimental to
performance to go fetch the xmin/xmaxes, but maybe it indeed wouldn't be
so bad if you could optimize the common case where there's no snapshots
in the standby. Also, if you have a very busy table where a lot of
tuples are killed, many of the heap pages will probably be in cache.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com