Re: BRIN indexes (was Re: Minmax indexes)

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