Skip site navigation (1) Skip section navigation (2)

strange nbtree corruption report

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: strange nbtree corruption report
Date: 2011-11-21 23:00:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

We got a very strange nbtree corruption report some time ago.  This was
a btree index on a vey high churn table -- entries are updated and
deleted very quickly, so the index grows very large and also shrinks
quickly (AFAICT this is a work queue of sorts).

The most strange thing of all is that there was this error:

ERROR:  left link changed unexpectedly in block 3378 of index "index_name" 
CONTEXT:  automatic vacuum of table "table_name"

This was reported not once, but several dozens of times, by each new
autovacuum worker that tried to vacuum the table.

As far as I can see, there is just no way for this to happen ... much
less happen repeatedly.  I thought it might be related to concurrent
insertions somehow managing to split the page under deletion very
quickly (given the load these systems are under, this is plausible).
But I can't find how.

(There were other error reports of btree indexes going awry here, such
as "ERROR: right sibling's left-link doesn't match: block 67 links to
2118 instead of expected 2228 in index "pg_depend_depender_index").

These guys are running 8.3.14 here, and this is a Londiste slave
database.  Sadly, it seems that the index files in our case are gone

I see three independent reports of this error message in the archives
(Ulrich Wisser, Mark Kirkwood, Gabriel Ferro), but no one seems to have
carried the investigation forward enough to discover what is exactly
going wrong.

Any thoughts about this?

Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>


pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-11-21 23:10:35
Subject: Re: testing ProcArrayLock patches
Previous:From: Robert HaasDate: 2011-11-21 22:55:18
Subject: Re: Inlining comparators as a performance optimisation

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group