From: | Hannu Krosing <hannu(at)skype(dot)net> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | 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-16 07:36:09 |
Message-ID: | 1171611369.3885.19.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2007-02-16 07:46:56 | pgsql: Functions for mapping table data and table schemas to XML (a.k.a. |
Previous Message | Jeremy Drake | 2007-02-16 07:02:33 | Re: patch adding new regexp functions |