Re: hung backends stuck in spinlock heavy endless loop

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: hung backends stuck in spinlock heavy endless loop
Дата
Msg-id CAM3SWZTZAJRtuZ1qcVrmSEWzN05dN6xRqkPq6OM7UbKUdpEtGw@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>)
Список pgsql-hackers
On Wed, Jan 14, 2015 at 11:49 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
> so it looks like nobody ever exits from _bt_moveright.   any last
> requests before I start bisecting down?

Could you write some code to print out the block number (i.e.
"BlockNumber blkno") if there are more than, say, 5 retries within
_bt_moveright()? You'll also want to print out the name of the index
(so rel->rd_rel->relname.data). That'll probably only trip when this
happens (5 retries are very unusual). Then, use contrib/pageinspect to
dump that block's contents (I think that'll work, since no one sits on
a buffer lock here).

I'd like to know what index we're dealing with here. I wonder if it's
"pg_attribute_relid_attnam_index".

So: call "bt_page_stats('pg_whatever', n)", n being the relevant block
number. Try and do the same with the right link (which bt_page_stats()
will show). Then try and call bt_page_items() against one or both of
those blocks/pages. I'd like to see what that shows. I'm wondering if
some invariant has been violated.

Which _bt_moveright() caller are we talking about here, BTW? I guess
it's just the _bt_first()/ _bt_search() one. That might vary, of
course.

-- 
Peter Geoghegan



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Memory leak in vacuumlo
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: hung backends stuck in spinlock heavy endless loop