Re: I s this a bug of spgist index in a heavy write condition?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: I s this a bug of spgist index in a heavy write condition?
Дата
Msg-id 11459.1357705723@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: I s this a bug of spgist index in a heavy write condition?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: I s this a bug of spgist index in a heavy write condition?  (李海龙 <hailong.li@qunar.com>)
Список pgsql-hackers
Дерево обсуждения 
I wrote:
> The control flow in spgdoinsert.c is flat enough that the stack trace
> alone isn't much help in understanding the bug, I'm afraid.

BTW, something that possibly *would* help, since you seem to be able to
reproduce the bug easily, is to do that and then capture the values of
the local variables in spgdoinsert() -- especially the contents of the
"current" and "parent" structs --- from each of the processes that are
stuck.  Also interesting would be to print the SpGistCache structs.
It'd go something likeframe 4info localsp *(SpGistCache *) index->rd_amcache
        regards, tom lane

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

Предыдущее
От: Hari Babu
Дата:
Сообщение: Re: Review of "pg_basebackup and pg_receivexlog to use non-blocking socket communication", was: Re: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: PL/perl should fail on configure, not make