On Tue, Jun 8, 2010 at 4:55 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Fri, 2010-06-04 at 10:18 -0400, Tom Lane wrote: >> Jan Wieck <janwi...@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
