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: | 1321915576-sup-7558@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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
now.
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>
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-11-21 23:10:35 | Re: testing ProcArrayLock patches |
Previous Message | Robert Haas | 2011-11-21 22:55:18 | Re: Inlining comparators as a performance optimisation |