On Thu, Jan 15, 2015 at 6:04 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > On 01/15/2015 03:23 AM, Peter Geoghegan wrote: >> >> So now the question is: how did that inconsistency arise? It didn't >> necessarily arise at the time of the (presumed) split of block 2 to >> create 9. It could be that the opaque area was changed by something >> else, some time later. I'll investigate more. > > > Merlin, could you re-run the test with a WAL archive (if you don't have one > already), and then run pg_xlogdump, filtering it to show only the changes to > the index? That should show us how the index got to be the way it is. Also, > if you could post a copy of the raw relation file for pg_class_oid_index; I > assume it's not too large. > > Something like: > > pg_xlogdump -r Btree -p walarchive/ -s 0/20035D0 | grep 11917 > > 11917 is the relfilenode of pg_class_oid_index on a freshly initdb'd > cluster. In case it's not the same on your system, you can use oid2name to > find it out.
I'm on it. Will try this first, then patch removal. Question: Coming in this morning I did an immediate restart and logged into the database and queried pg_class via index. Everything was fine, and the leftright verify returns nothing. How did it repair itself without a reindex? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers