Pavan Deolasee wrote:
> - We need to find a way to handle DEAD root tuples, either convert them
> into
> stubs or overwrite them with a new version. We can also perform pointer
> swinging from the index. Again there are concerns about crash-safety and
> concurrent index-scans working properly. We don't have a community
> consensus on any of the suggestions in this regard. But hopefully we
> would converge on some design soon.
This seems to be the most fundamental problem we have at the moment. If
we stick to the basic rule we have now that a live tuple's ctid doesn't
change, the only way to get rid of a dead tuple at the root of the
update chain is by changing the index pointer. The backward-pointers
Hannu suggested or the "scan the whole page to find the previous tuple"
would allow reuse of those dead tuples for new tuples in the chain, but
even those methods wouldn't completely eliminate the problem.
We could say that in some scenarios we just leave behind some dead
tuples/stubs that can never be reclaimed. What do you guys think, if we
can bring it down to just an extra line pointer, would that be
acceptable? We could also do that for now and implement the
pointer-swinging later if it turns out to be a problem in practice.
What's the verdict on relaxing the "live tuple's ctid doesn't change
rule"? If we did allow that within a page, what would we need to change? Inside the backend we'd have to make sure
thatwhenever a ctid is
used, the page is kept pinned. How likely is it that it would brake any
external projects, and how difficult would it be to detect the broken
usage pattern? It would mean that the ctid system column could change
within a transaction, unless we change it so that it returns the ctid of
the root tuple + xmin + cmin, but it'd be a user-visible change anyhow.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
