FAQ
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

Search Discussions

  • Tom Lane at Jul 16, 2007 at 2:32 pm

    Heikki Linnakangas 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
  • Heikki Linnakangas at Jul 16, 2007 at 2:40 pm

    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
  • Tom Lane at Jul 16, 2007 at 3:21 pm

    Heikki Linnakangas 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
  • Hannu Krosing at Jul 16, 2007 at 2:34 pm
    Ü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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 16, '07 at 2:24p
activeJul 16, '07 at 3:21p
posts5
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase