On Wed, Jun 2, 2010 at 3:10 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of mié jun 02 14:16:33 -0400 2010:
>
>> We could, but I think we'd be better off just freezing at the time we
>> mark the page PD_ALL_VISIBLE and then using the visibility map for
>> both purposes. Keeping around the old xmin values after every tuple
>> on the page is visible to every running transaction is useful only for
>> forensics, and building a whole new freeze map just to retain that
>> information longer (and eventually force a massive anti-wraparound
>> vacuum) seems like overkill.
>
> Reducing the xid wraparound horizon "a bit" is reasonable, but moving it
> all the way forward to OldestXmin is a bit much, methinks.
Why? If it's just for forensics, those are some pretty expensive
forensics - it eventually costs you an additional complete rewrite of
every page.
> Besides, there's another argument for not freezing tuples immediately:
> they may be updated shortly thereafter, causing extra churn for no gain.
But if you were going to update PD_ALL_VISIBLE, then you were going to
write the page anyway. You might as well freeze everything at the
same time so you don't have to come back.
Alternatively, you could do what I suggested upthread and just believe
PD_ALL_VISIBLE over the individual tuple xmins. Then you don't have
to freeze the page until it's next written, but you still get to keep
your forensic info.
> 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?)
Not me. I don't think that's going to help a whole lot, though. In
many of the painful scenarios, every tuple on the page will have the
same XID, and therefore they'll all be frozen at the same time anyway.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
