From: Michael Widenius Date: July 16 2009 4:37pm Subject: Re: is MySQL bug #44373 really a bug? List-Archive: http://lists.mysql.com/internals/37195 Message-Id: <19039.22330.434659.850959@narttu.askmonty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! >>>>> "Zardosht" == Zardosht Kasheff writes: Zardosht> Hello Sergei, Zardosht> The bitmap was not a strict subset. The reason I was able to find the Zardosht> problem was that because the bitmap was not a subset, the query Zardosht> returned an incorrect result. Upon investigation, I found the problem. >>> Some time back, I filed MySQL bug #44373, because comments in the >>> Handler API led me to believe it is a bug. However, I was never really >>> sure. I may be misunderstanding the intended API contracts. What I am >>> wondering is this. Is my understanding correct, and this is a bug, or >>> is my understanding of the behavior of column_bitmaps_signal with >>> respect to the handler::position API not correct? >> >> From what you've written in the bug report it looks like it's a genuine >> bug. >> >> But - admittedly - I didn't try to extract a small test case out of >> test-ATIS and run it in a debugger. >> >> Is the new bitmap a strict subset of the old one ? I remember >> discussions that NDB needs to know the bitmap before the scan starts >> (e.g. before index_init) because it sends it (bitmap) to other nodes, >> and we were talking about an optimization where MySQL could remove >> columns from a bitmap after the scan started - but the engine was not >> required to obey it, indeed, it's always ok to return more columns than >> what was requested. But even in this case column_bitmaps_signal() >> should've been called. Still a bug. No, the new bitmap may be totally unrelated to the old one. For example, MySQL may first do an ORDER by optimization and use a bitmap that only fetches the row id + what is in the ORDER BY part and then later it may fetch the whole rows. >> If a new bitmap is not a strict subset of the old one then it's a much >> worse bug, and it probably would deliver incorrect query results (or >> worse) with ndb. It's a not a bug; The interface is designed with the idea what the map can change any time in any way. It shouldn't be hard to inform the NDB nodes for bitmap changes if this is a problem. Regards, Monty