On Tue, 2010-06-08 at 16:58 -0400, Robert Haas wrote:
> On Tue, Jun 8, 2010 at 4:55 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > On Fri, 2010-06-04 at 10:18 -0400, Tom Lane wrote:
> >> Jan Wieck <JanWieck@Yahoo.com> writes:
> >> > On 6/2/2010 3:10 PM, Alvaro Herrera wrote:
> >> >> I'd prefer a setting that would tell the system to freeze all tuples
> >> >> that fall within a safety range whenever any tuple in the page is frozen
> >> >> -- weren't you working on a patch to do this? (was it Jeff Davis?)
> >>
> >> > I just see a lot of cost caused by this "safety range". I yet have to
> >> > see its real value, other than "feel good".
> >>
> >> Jan, you don't know what you're talking about. I have repeatedly had
> >> cases where being able to look at xmin was critical to understanding
> >> a bug. I *will not* hold still for a solution that effectively reduces
> >> min_freeze_age to zero.
> >
> > Recent history shows Tom's view to be the most useful one: its useful to
> > keep seeing the xmin. The last time we altered the way we set hint bits
> > we caused multiple data loss bugs doing it. We will need to debug things
> > and the WAL is always long gone (great idea though).
> >
> > Why not just have a separate flag for HEAP_XMIN_FROZEN, that way we can
> > keep the xmin but also can see it is frozen?
>
> We could do that, but I think the point of this exercise is to reduce
> I/O - specifically, I/O caused by anti-wraparound vacuums - and I'm
> not clear how such a flag would help with that.
Hmmm: You suggested a variant of this idea, so whatever reasoning was
behind your suggestion would be shared here, surely?
Tom has been saying we cannot freeze early because we need to keep
xmins. I agree with that. This suggestion shows it is possible to freeze
a tuple AND keep its xmin. So that removes the argument that we should
freeze more aggressively (whenever we write the block) and can thus
reduce longer term I/O costs.
-- Simon Riggs www.2ndQuadrant.com
