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).
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
