Re: BRIN indexes (was Re: Minmax indexes) - Mailing list pgsql-hackers

From Emanuel Calvo
Subject Re: BRIN indexes (was Re: Minmax indexes)
Date
Msg-id 54163C0F.7060907@esdebian.org
Whole thread Raw
In response to BRIN indexes (was Re: Minmax indexes)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: BRIN indexes - TRAP: BadArgument  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
<br /><div class="moz-cite-prefix">El 08/09/14 13:02, Alvaro Herrera escribió:<br /></div><blockquote
cite="mid:20140908160219.GN14037@eldon.alvh.no-ip.org"type="cite"><pre wrap="">Here's version 18.  I have renamed it:
Theseare now BRIN indexes.
 

I have fixed numerous race conditions and deadlocks.  In particular I
fixed this problem you noted:

Heikki Linnakangas wrote:
</pre><blockquote type="cite"><pre wrap="">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.
</pre></blockquote><pre wrap="">
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.
</pre></blockquote><br /> Debuging VACUUM VERBOSE ANALYZE over a concurrent table being updated/insert.<br /><br />
(gbd)<br/> Breakpoint 1, errfinish (dummy=0) at elog.c:411<br /> 411        ErrorData  *edata =
&errordata[errordata_stack_depth];<br/><br /> The complete backtrace is at <a class="moz-txt-link-freetext"
href="http://pastebin.com/gkigSNm7">http://pastebin.com/gkigSNm7</a><br/><br /><br /> Also, I found pages with an
unkowntype (using deafult parameters for the index<br /> creation):<br /><br />  brin_page_type | array_agg<br />
----------------+-----------<br/>  unknown (00)   | {3,4}<br />  revmap         | {1}<br />  regular        | {2}<br />
 meta          | {0}<br /> (4 rows)<br /><br /><br /><br /><br /><blockquote
cite="mid:20140908160219.GN14037@eldon.alvh.no-ip.org"type="cite"><pre wrap="">
 
</pre><br /><fieldset class="mimeAttachmentHeader"></fieldset><br /><pre wrap="">
</pre></blockquote><br /><pre class="moz-signature" cols="72">-- 
--
Emanuel Calvo
@3manuek</pre>

pgsql-hackers by date:

Previous
From: Arthur Silva
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes
Next
From: Robert Haas
Date:
Subject: Re: pgbench throttling latency limit