| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | 李海龙 <hailong(dot)li(at)qunar(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, 何伟平 <weiping(dot)he(at)qunar(dot)com>, 王冬 <dong(dot)wang(at)qunar(dot)com>, 于超超 <chaochao(dot)yu(at)qunar(dot)com> |
| Subject: | Re: I s this a bug of spgist index in a heavy write condition? |
| Date: | 2013-01-09 04:28:43 |
| Message-ID: | 11459.1357705723@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 like
frame 4
info locals
p *(SpGistCache *) index->rd_amcache
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2013-01-09 04:32:54 | Re: PL/perl should fail on configure, not make |
| Previous Message | Hari Babu | 2013-01-09 04:02:58 | 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 |