Thread: Dealing with dangling index pointers
While looking at the HOT patch, I noticed that if there's an index tuple pointing to a non-existing heap tuple, we just silently ignore it. Such dangling index entries of course means that your database is corrupt, but we ought to handle that better. In the worst case, the heap slot is inserted to in the future, and then the bogus index entry points to a wrong tuple. ISTM we should print a warning suggesting a REINDEX, and kill the index tuple. Killing tuples in the face of corruption is dangerous, but in this case I think it's the right thing to do. We could also just emit the warning, but that could fill the logs quickly if the index tuple is accessed frequently. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas <heikki@enterprisedb.com> writes:
> While looking at the HOT patch, I noticed that if there's an index tuple
> pointing to a non-existing heap tuple, we just silently ignore it.
This is intentional --- consider case where VACUUM has removed both
index and heap entries while some other (amazingly slow...) process is
in flight from the index to the heap.
regards, tom lane
Ühel kenal päeval, E, 2007-07-16 kell 15:23, kirjutas Heikki Linnakangas: > While looking at the HOT patch, I noticed that if there's an index tuple > pointing to a non-existing heap tuple, we just silently ignore it. > > Such dangling index entries of course means that your database is > corrupt, but we ought to handle that better. In the worst case, the heap > slot is inserted to in the future, and then the bogus index entry points > to a wrong tuple. > > ISTM we should print a warning suggesting a REINDEX, and kill the index > tuple. Killing tuples in the face of corruption is dangerous, but in > this case I think it's the right thing to do. We could also just emit > the warning, but that could fill the logs quickly if the index tuple is > accessed frequently. maybe issue a warning and set the DELETED index bit ? marking the invalid pointer as deleted should make it effectively disappear from use, without adding too much complexity ------------- Hannu
Tom Lane wrote: > Heikki Linnakangas <heikki@enterprisedb.com> writes: >> While looking at the HOT patch, I noticed that if there's an index tuple >> pointing to a non-existing heap tuple, we just silently ignore it. > > This is intentional --- consider case where VACUUM has removed both > index and heap entries while some other (amazingly slow...) process is > in flight from the index to the heap. Hmm. In b-tree we keep the index page pinned while we do the heap fetch to avoid that, but apparently we don't have that interlock in other indexams. Ok, never mind. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Tom Lane wrote:
>> This is intentional --- consider case where VACUUM has removed both
>> index and heap entries while some other (amazingly slow...) process is
>> in flight from the index to the heap.
> Hmm. In b-tree we keep the index page pinned while we do the heap fetch
> to avoid that, but apparently we don't have that interlock in other
> indexams.
Right. This is actually connected to the fact that only btrees are used
as system catalog indexes, and so only btrees need to be safe for use
with SnapshotNow semantics. If VACUUM has managed to remove the target
tuple while we are "in flight", then it's further possible that someone
else has inserted something new into that same tuple slot, and maybe
even committed by the time we get there. Under SnapshotNow rules we
would take the new tuple as a valid search result, though it (probably)
doesn't actually satisfy the index search condition. With any MVCC-safe
snapshot we will reject the new tuple as not meeting the snapshot.
(BTW, this answers Teodor's question awhile back about whether he could
use a GIN index in a system catalog. Nope, not without more work on
index interlocking.)
regards, tom lane