From: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Bruce Momjian" <bruce(at)momjian(dot)us>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "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-15 10:23:10 |
Message-ID: | E1539E0ED7043848906A8FF995BDA57901C1394B@m0143.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> Just to summarize:
>
> o Every tuple gets a heap ctid
> o Only the root tuple gets an index entry
> o We can easily remove dead tuples that aren't the root because
> by definition, nothing points to them, including backends and
> indexes
I am still wondering about the "easily" here. Basically this
needs some kind of wal entry to be crash safe.
Else some later tx might reuse the slot:
- some update on page produces page image in wal
- slot removed
- slot reused and comitted
- page not written
- crash
- wal fullpage restores the page to the version before slot
removed
(- would need a wal replay for slot removed from hot chain here)
- wal restores slot reuse, but the slot is now part of a wrong
hot chain
and the chain is broken (unless we have the above step)
Do we have this wal entry ?
> The problem is that a dead root tuple has to stay around
> because while no backends can see it, the index does. We
> could move a live tuple into root ctid slot, but if we do
> that, the live tuple changes its ctid while it is visible.
>
> Could we insert index tuples for the live tuple and then
> remove the root tuple, perhaps later? So basically we break
> the chain at that time.
> The problem there is that we basically have nothing better
> than what we have now --- we are just delaying the index
> insert, and I don't see what that buys us.
yes, not really promising.
> Could a _new_ tuple take over the root tuple slot? It is
> new, so it doesn't have a ctid yet to change. I think that
> means the index walking
> could go forward or backward, but on the same page. To illustrate,
> with ctid slot numbers:
>
> [1] root INSERT
> [2]
> [3]
>
> [1] root INSERT
> [2] UPDATE
> [3]
>
> [1] root INSERT (dead)
> [2] UPDATE 1
> [3]
>
> [1] root UPDATE 2
> [2] UPDATE 1
> [3]
Imho no, because that would need a back pointer in [1] to [2] so that
readers arriving at [1] (e.g. through index) can see [2] until [1] is
visible.
I think we don't want backpointers. (rather go the tuple swapping route)
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-02-15 10:49:31 | Re: HOT WIP Patch - version 1 |
Previous Message | Peter Eisentraut | 2007-02-15 09:57:45 | Re: patch adding new regexp functions |