=?gb2312?B?wO66o8H6?= <hailong...@qunar.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
