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.
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).
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/