Skip site navigation (1) Skip section navigation (2)

Re: Single Index Tuple Chain (SITC) method

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Greg Stark <gsstark(at)mit(dot)edu>, PFC <lists(at)peufeu(dot)com>
Subject: Re: Single Index Tuple Chain (SITC) method
Date: 2006-06-28 22:19:20
Message-ID: 8443.1151533160@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <bruce(at)momjian(dot)us> 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.
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.

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.
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.)

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-06-28 22:30:34
Subject: Re: Instability in TRUNCATE regression test
Previous:From: Bruce MomjianDate: 2006-06-28 18:16:29
Subject: Single Index Tuple Chain (SITC) method

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group