Skip site navigation (1) Skip section navigation (2)

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

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 (view raw or flat)
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


In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2013-01-09 04:32:54
Subject: Re: PL/perl should fail on configure, not make
Previous:From: Hari BabuDate: 2013-01-09 04:02:58
Subject: 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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group