Re: GiST notice

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).
> 
>