Teodor Sigaev wrote:
> It should be mentioned in documentation that after pgsql's crash GiST
> indexes may restore some "incorrect way": with invalid tuples. Of
> course, not every time. Index will work absolutly correct but possibly
> with some performance degradation (not big). 'Vacuum full' resolves this
> problem and repairs invalid tuples.
Can you also use reindex?
Sincerely,
Joshua D. Drake
> If that problem is detected during recovery, postgres says to log :
> LOG: Detected incomplete insert into GiST index 1663/16385/16458; It's
> desirable to vacuum or reindex index
> More, if usial vacuum will say on such index:
> NOTICE: It's desirable to vacuum full or reindex GiST index 'idx' due
> to crash recovery
> Sorry, but my English doesn't make it possible to write correct phrase
> to documentation. May be thats phrases too...
>
>
> Just for reminder, I found strange trap on vacuum running concurrently
> with a lot of other queries:
> http://www.pgsql.ru/db/mw/msg.html?mid=2077426
> http://www.pgsql.ru/db/mw/msg.html?mid=2078029
> In short:
> it caused approximatly one time per 2-4 million statements (with my
> scripts at http://www.sigaev.ru/gist/, PIII/1133 MHz and Quad
> Xeon/500MHz), I got traps:
> TRAP: FailedAssertion("!((*curpage)->offsets_used == num_tuples)", File:
> "vacuum.c", Line: 2766)
> LOG: server process (PID 15847) was terminated by signal 6
> It's definitly bug in a vaccum code, I got the same trap without any GiST
> indexes (to reproduce, just comment out 'create index' command in my
> script).
>
>