Re: HOT WIP Patch - version 1 - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: HOT WIP Patch - version 1
Date
Msg-id 1171611369.3885.19.camel@localhost.localdomain
Whole thread Raw
In response to Re: HOT WIP Patch - version 1  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: HOT WIP Patch - version 1  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
Ühel kenal päeval, N, 2007-02-15 kell 10:49, kirjutas Heikki
Linnakangas:

> We already log tuple removals by normal vacuums. We can't use that wal 
> entry as it is: if a dead tuple is in the middle of an update chain, it 
> needs to be unlinked from the chain. But I don't see any particular 
> problem with that, it just needs to be wal logged like every other data 
> changing operation.
> 
> Do we actually ever want to remove dead tuples from the middle of the 
> chain? If a tuple in the middle of the chain is dead, surely every tuple 
> before it in the chain is dead as well, and we want to remove them as 
> well. I'm thinking, removing tuples from the middle of the chain can be 
> problematic, because we'd need to fiddle with the xmin/xmax of the other 
> tuples to make them match. Or change the tuple-following logic to not do 
> the xmin=xmax check, but it's a nice robustness feature.

What kind of robustness does it provide ? In other words - what failure
scenario does this guard against ?

I can't see the case where the xmin=xmax check can not succeed, at least
not for same page tuples.

-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com




pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Mail getting through?
Next
From: Peter Eisentraut
Date:
Subject: Re: [COMMITTERS] pgsql: Functions for mapping table data and table schemas to XML (a.k.a.