On Thu, Jan 15, 2015 at 6:04 AM, Heikki Linnakangas
<hlinnakangas@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