Re: hung backends stuck in spinlock heavy endless loop
От | Heikki Linnakangas |
---|---|
Тема | Re: hung backends stuck in spinlock heavy endless loop |
Дата | |
Msg-id | 54B7ACC8.90909@vmware.com обсуждение исходный текст |
Ответ на | Re: hung backends stuck in spinlock heavy endless loop (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: hung backends stuck in spinlock heavy endless loop
|
Список | 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
В списке pgsql-hackers по дате отправления: