Re: hung backends stuck in spinlock heavy endless loop

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: hung backends stuck in spinlock heavy endless loop
Дата
Msg-id CAM3SWZSOUPKDC2m+T4Bs2Mp0ca+Q-S76DrEo6O=L=G+V4Rn1Bg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: hung backends stuck in spinlock heavy endless loop  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: hung backends stuck in spinlock heavy endless loop  (Peter Geoghegan <pg@heroku.com>)
Re: hung backends stuck in spinlock heavy endless loop  (Peter Geoghegan <pg@heroku.com>)
Re: hung backends stuck in spinlock heavy endless loop  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
On Wed, Jan 14, 2015 at 4:53 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> yeah.  via:
> cds2=# \copy (select s as page, (bt_page_items('pg_class_oid_index',
> s)).* from generate_series(1,12) s) to '/tmp/page_items.csv' csv
> header;

My immediate observation here is that blocks 2 and 9 have identical
metadata (from their page opaque area), but partially non-matching
data items (however, the number of items on each block is consistent
and correct according to that metadata, as far as it goes). I think
block 9 is supposed to have a right-link to block 5 (block 5 seems to
think so, at least -- its left link is 9).

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.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Turning recovery.conf into GUCs
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Typo fix in alter_table.sgml