Re: 8.4b2 tsearch2 strange error
От | Tatsuo Ishii |
---|---|
Тема | Re: 8.4b2 tsearch2 strange error |
Дата | |
Msg-id | 20090606.124558.99245387.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: 8.4b2 tsearch2 strange error (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Well, I found at least part of the problem: > http://archives.postgresql.org/message-id/20090606023940.BD4B875331E@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
В списке pgsql-hackers по дате отправления: