Re: HOT WIP Patch - version 1

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Hannu Krosing" <hannu(at)skype(dot)net>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
Subject: Re: HOT WIP Patch - version 1
Date: 2007-02-20 07:12:09
Message-ID: 1171955530.25938.535.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-02-20 07:19:50 Re: HOT WIP Patch - version 1
Previous Message Pavel Stehule 2007-02-20 06:58:22 Re: ToDo: add documentation for operator IS OF