Thread: GiST notice
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/
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). > >
On Wed, 6 Jul 2005, Joshua D. Drake wrote: > 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? of course ! > > 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 > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83