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-08 22:10:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
=?gb2312?B?wO66o8H6?= <hailong(dot)li(at)qunar(dot)com> writes:
> I am very excited to say that I may have created a test case!

I've been running variants of this example for most of the afternoon,
and have not seen a failure :-(.  So I'm afraid there is some aspect
of your situation that you've not provided enough information to
reproduce.  Most likely, that's the initial contents of your table,
which you didn't provide.  I tried seeding the table with the five
values you did show and then running the insertion loops, but no luck,
even after many millions of insertions with various timing changes.

Please see if you can put together a self-contained test case including
necessary test data.  (Note there's no reason to think that any of the
columns other than the spgist-indexed one are interesting, if that helps
you sanitize the data to the point you can let it out.)

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.  We can
guess that two insertions are trying to lock the same two index pages in
opposite orders, but without looking at the data that doesn't put us
much closer to a fix.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Pavel StehuleDate: 2013-01-08 22:12:21
Subject: Re: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Previous:From: Stephen FrostDate: 2013-01-08 22:09:47
Subject: Index build temp files

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