Re: hung backends stuck in spinlock heavy endless loop

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: hung backends stuck in spinlock heavy endless loop
Date: 2015-01-15 12:04:24
Message-ID: 54B7ACC8.90909@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-01-15 12:06:53 Re: Fillfactor for GIN indexes
Previous Message Amit Kapila 2015-01-15 12:00:41 Re: parallel mode and parallel contexts