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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company