Ühel kenal päeval, K, 2006-06-28 kell 18:19, kirjutas Tom Lane: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Here is an overview of the SITC method: > > http://momjian.us/cgi-bin/pgsitc > > A pretty fundamental problem is that the method assumes it's OK to > change the CTID of a live tuple (by swapping its item pointer with some > expired version). It is not --- this will break: > * active UPDATEs and DELETEs that may have fetched the CTID > but not yet completed processing to decide whether to change > the tuple; > * pending AFTER ROW triggers, such as foreign key checks; > * ODBC as well as other applications that assume CTID is a > usable unique row identifier within transactions.
We should *always* return the ctid of CITC head, as this is the one that does not change. And anyway, ctid is a usable unique row identifier only within read-only transactions, or not ? > VACUUM FULL can get away with moving tuples to new CTIDs because it takes > AccessExclusiveLock, so there can be no open transactions with knowledge > of current CTIDs in the table. This is not OK for something that's > supposed to happen in plain UPDATEs, though. Would it still be a problem, if we *always* refer to the whole CITC chain by its externally visible ctid, an look up the real tuple inside tuple fetch op at every access. (1) If we had some special bits for tuples at CITC chain head and inside CITC but not at head, then even seqscan can ignore non-head CITC chain members at its find next tuple op and do the real tuple lookup in some inner function when it hits CITC head. Is it correct to assume, that only one row version can be in process of being modified at any one time? > Another problem is you can't recycle tuples, nor item ids, without > taking a VACUUM-style lock on the page (LockBufferForCleanup). If > anyone else is holding a pin on the page they risk getting totally > confused --- for instance, a seqscan will either miss a tuple or scan it > twice depending on which direction you're juggling item ids around it. I think (1) above solves this, at cost of looking twice at CITC internal tuple headers. > The concurrency loss involved in LockBufferForCleanup is OK for > background-maintenance operations like VACUUM, but I seriously doubt > anyone will find it acceptable for UPDATE. It could easily create > application-level deadlocks, too. (VACUUM is safe against that because > it only holds one lock.) Tom - what do you think of the other related idea, that of reusing dead index entries ? -- ---------------- 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend