Re: I s this a bug of spgist index in a heavy write condition?
В списке pgsql-hackers по дате отправления:
| От | 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?
|
| Список | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера