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 that whenever 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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to