El 08/09/14 13:02, Alvaro Herrera escribió: > Here's version 18. I have renamed it: These are now BRIN indexes. > > I have fixed numerous race conditions and deadlocks. In particular I > fixed this problem you noted: > > Heikki Linnakangas wrote: >> Another race condition: >> >> If a new tuple is inserted to the range while summarization runs, >> it's possible that the new tuple isn't included in the tuple that >> the summarization calculated, nor does the insertion itself udpate >> it. > I did it mostly in the way you outlined, i.e. by way of a placeholder > tuple that gets updated by concurrent inserters and then the tuple > resulting from the scan is unioned with the values in the updated > placeholder tuple. This required the introduction of one extra support > proc for opclasses (pretty simple stuff anyhow). > > There should be only minor items left now, such as silencing the > > WARNING: concurrent insert in progress within table "sales" > > which is emitted by IndexBuildHeapScan (possibly thousands of times) > when doing a summarization of a range being inserted into or otherwise > modified. Basically the issue here is that IBHS assumes it's being run > with ShareLock in the heap (which blocks inserts), but here we're using > it with ShareUpdateExclusive only, which lets inserts in. There is no > harm AFAICS because of the placeholder tuple stuff I describe above.
Debuging VACUUM VERBOSE ANALYZE over a concurrent table being updated/insert. (gbd) Breakpoint 1, errfinish (dummy=0) at elog.c:411 411 ErrorData *edata = &errordata[errordata_stack_depth]; The complete backtrace is at http://pastebin.com/gkigSNm7 Also, I found pages with an unkown type (using deafult parameters for the index creation): brin_page_type | array_agg ----------------+----------- unknown (00) | {3,4} revmap | {1} regular | {2} meta | {0} (4 rows) > > -- -- Emanuel Calvo @3manuek
