Re: BRIN indexes (was Re: Minmax indexes)
От | Emanuel Calvo |
---|---|
Тема | Re: BRIN indexes (was Re: Minmax indexes) |
Дата | |
Msg-id | 54163C0F.7060907@esdebian.org обсуждение исходный текст |
Ответ на | BRIN indexes (was Re: Minmax indexes) (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: BRIN indexes - TRAP: BadArgument
(Alvaro Herrera <alvherre@2ndquadrant.com>)
|
Список | 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 по дате отправления: