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
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 |