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