[Monetdb-developers] GDKupgradevarheap allocate/copy inconsistency

Martin Kersten Martin.Kersten at cwi.nl
Fri Jan 22 19:58:35 CET 2010


Isidor Zeuner wrote:
>>> [1] https://sourceforge.net/tracker/?func=detail&aid=2936616&group_id=56967&atid=482468
>> I saw the tracker item, and was wondering about it.
>>
>> What did you do to get into the situation?  In other words, how can I
>> reproduce?
>>
> 
> Unfortunately, I don't have an isolated failing case yet. I am
> continuously sending queries (mostly SELECT, INSERT and DELETE) using
> MonetDB-SQL, many of which are grouped inside large
> transactions. After initializing the database, it takes a while for
> the issue to occur, and I'm not yet sure what triggers it.
> 
> I am currently adding instrumentation code around the code
> communicating with Mapi, which will hopefully get me some reproducible
> sessions for this and the other issue I am seeing
FYI. The stethoscope program can be attached to any running mserver
to extract information about the instructions being executed and
the necessary performance indicators.

> 
>> I don't think BATs created in VIEWcreate_ should end up in
>> GDKupgradevarheap.  Those BATs are views, and I would think views are
>> read-only, and read-only BATs should not end up here.
>>
> 
> Yes, intuitively it seemed a bit unusual when I thought about it, but
> then again I am not much used to the MonetDB internals yet.
> 
> I had found GDKupgradevarheap being supplied with a capacity less than
> heap.size >> shift (it was capacity == 256, heap.size == 512 and shift
> == 0), and was wondering where it came from. So I added assert
> statements to all locations modifying capacity, shift or the heap
> allocation, which errored out in VIEWcreate_. It happened about the
> same time where I would have expected the GDKupgradevarheap issue to
> occur, so I found it most likely to be related.
> 
> Of course the problematic BAT might still come from another source, so
> if you say views won't reach GDKupgradevarheap, I'll probably
> go for another run without the assertions in VIEWcreate_. On the other
> hand, will it suffice to put assert(!isVIEW(b)) statements in front of
> the GDKupgradevarheap calls in the code to verify?
> 
>> The BAT capacity is the number of elements that can be stored in the
>> BAT, i.e. it is exactly the size of the heap (apart from the
>> multiplication with the width of the elements).  However, this may break
>> down in the case of views.  When I wrote the code, I wasn't thinking of
>> views, since I didn't expect them to end up here, and I still think they
>> shouldn't.
>>
>> Having said this, it is probably possible, perhaps even equivalent, to
>> use the size as you suggested instead of the capacity -- as long as
>> views are left out of the equation.
>>
> 
> So, as views aren't supposed to get there anyway, capacity is
> redundant in that function, right?
> 
> Best regards,
> 
> Isidor Zeuner
> 
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Monetdb-developers mailing list
> Monetdb-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-developers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_kersten.vcf
Type: text/x-vcard
Size: 293 bytes
Desc: not available
URL: <http://www.monetdb.org/pipermail/developers-list/attachments/20100122/ede55b08/attachment.vcf>


More information about the developers-list mailing list