Message-ID: <42CC057A.9060105@commandprompt.com>
Date: Wed, 06 Jul 2005 09:23:22 -0700
From: "Joshua D. Drake" <jd@commandprompt.com>
Organization: Command Prompt, Inc.
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Teodor Sigaev <teodor@sigaev.ru>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>,
	Bruce Momjian <pgman@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: GiST notice
References: <42CBFE69.9070408@sigaev.ru>
In-Reply-To: <42CBFE69.9070408@sigaev.ru>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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