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

Re: A thought on Index Organized Tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Karl Schnaitter <karlsch(at)gmail(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A thought on Index Organized Tables
Date: 2010-02-26 21:30:34
Message-ID: 5335.1267219834@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> writes:
>> It does.  The point is that the system is set up to limit the bad
>> consequences.  You might (will) get wrong query answers, but the
>> heap data won't get corrupted.
>> 
> Again Tom, if there is an update based on index scan, then it takes the
> tupleid and updates the wrong heap data right?

No, what generally happens is it fails to find a matching index entry at
all, because the search algorithm concludes there can be no match based
on the limited set of comparisons it's done.  Transitivity failures lead
to searching the wrong subset of the index.

The case you're thinking about could arise if VACUUM failed to clean out
an index entry; after some unrelated tuple is inserted at the
just-cleared TID, searches finding that index entry would mistakenly
process the new tuple.  This is why we insist on VACUUM not assuming
very much about the consistency of the index.

It's also a problem for thick indexes, because if you try to do a normal
index search for the index tuple to update its copy of the tuple
xmin/xmax data, you might fail to find it --- but that doesn't mean it's
not there.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-02-26 21:39:12
Subject: Re: Hot Standby query cancellation and Streaming Replication integration
Previous:From: Greg StarkDate: 2010-02-26 21:22:47
Subject: Re: Hot Standby query cancellation and Streaming Replication integration

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