On Fri, 2007-02-16 at 09:36 +0200, Hannu Krosing wrote:
> Ü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.
The xmin == xmax case was required to support a complex VACUUM FULL
failure case discovered some time ago. I'll post the details.
With HOT, ISTM that testing this becomes even more important in some
form because of the extra complexity we're putting into that part of the
code. We need some way of detecting a corruption introduced by some
weird use case we haven't thought of.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
