> Well, I found at least part of the problem: > http://archives.postgresql.org/message-id/20090606023940.bd4b8753...@cvs.postgresql.org > > This is in perfectly sequential code. The reason it has > nondeterministic effects is that (so far as I can tell) the only > non-crash case where there would be duplicate TIDs to eliminate is if > two backends are concurrently flushing an index's pending-inserts list. > The code is designed to let that happen and suppress the duplicates at > the very end of the process, in addItemPointersToTuple(); but the > duplicate-removal logic was broken and allowed extra garbage TIDs to > creep in. So at least in the case I'm testing, this happens when > autovacuum fires on the table concurrently with a large insertion. > > Please update to CVS HEAD, reindex that index, and then see if you see > any more strange behavior. I'm not entirely convinced that this is the > only problem ...
Thanks for investigating the problem. Using CVS HEAD and reindexing has solved the problems I reported. On Monday I will ask my engineers try the CVS HEAD and do more operations to see if any strange thing happen... -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
