Re: [HACKERS] Backend crashes (6.5.2 linux) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Backend crashes (6.5.2 linux)
Date
Msg-id 9684.941511987@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Backend crashes (6.5.2 linux)  (Michael Simms <grim@argh.demon.co.uk>)
List pgsql-hackers
Michael Simms <grim@argh.demon.co.uk> writes:
> Vadim Wrote:
>> This FATAL means that index is broken (some prev insertion
>> was interrupted by elog(ERROR) or backend crash) - try to rebuild...

> Thats curious cos look at this explain...

> bestadssearch=> explain update search_url set stale=941424005 where lowerurl='http://criswell.bizland.com';
> NOTICE:  QUERY PLAN:

> Seq Scan on search_url  (cost=1546.06 rows=2 width=122)

> That does a seq scan not an index scan.

No, the elog message is coming out of btree index *update*, not
btree scan.  Since you're doing an update, new index entries have
to be made for the tuple being updated, regardless of what kind
of scan was used to find it.  And the message comes out because
the attempt to insert an index entry is finding that the index is
already corrupt.

Vadim's advice is probably the best: drop and recreate the index(es)
on that table.  You shouldn't need to dump the table itself, unless
there's more going on than is apparent from the info so far.

> I am going to rebuild the table (dump and reload) but before I do,
> does anyone want me to try anything on it to see if you can get any
> more information you may need for debugging? If so, let me know asap

If you can reproduce the sequence of events that led to the index
becoming corrupted, that'd be *really* useful debugging info.  But
it's probably too late to reconstruct anything very helpful from
the current state of the index.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] sort on huge table
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Function-manager redesign: second draft (long)