Re: hung backends stuck in spinlock heavy endless loop - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: hung backends stuck in spinlock heavy endless loop
Date
Msg-id CAHyXU0xAj42RuTBRFPfQD1BAkTC__+4eysV0VbiH8u5-i1o91Q@mail.gmail.com
Whole thread Raw
In response to Re: hung backends stuck in spinlock heavy endless loop  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: hung backends stuck in spinlock heavy endless loop
Re: hung backends stuck in spinlock heavy endless loop
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Safe memory allocation functions
Next
From: Amit Kapila
Date:
Subject: Re: parallel mode and parallel contexts