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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-02-26 21:39:12 | Re: Hot Standby query cancellation and Streaming Replication integration |
Previous Message | Greg Stark | 2010-02-26 21:22:47 | Re: Hot Standby query cancellation and Streaming Replication integration |