Re: Summary and Plan for Hot Standby - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Summary and Plan for Hot Standby
Date
Msg-id 4B06EAE2.6090206@enterprisedb.com
Whole thread Raw
In response to Re: Summary and Plan for Hot Standby  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: Prettification versus dump safety
Next
From: Heikki Linnakangas
Date:
Subject: Re: [COMMITTERS] pgsql: /home/peter/commit-msg