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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Ü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



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend