Re: [HACKERS] Backend crashes (6.5.2 linux)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Backend crashes (6.5.2 linux)
Дата
Msg-id 9684.941511987@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Backend crashes (6.5.2 linux)  (Michael Simms <grim@argh.demon.co.uk>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] sort on huge table
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Function-manager redesign: second draft (long)