I wrote: > ... What I think is happening is that there's some inadequately > locked page-changing logic in there, and if you can get autovacuum to > happen on msginfo concurrently with the data reload step, it'll mess up. > Given that we've not seen reports of this on 8.3, I'll bet lunch that > the bug is somewhere in the "fast insert" code. I haven't found it > yet, though.
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 ... 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
