Hi Serg! On Tue, Jun 9, 2015 at 1:24 AM, Sergei Golubchik <serg@mariadb.org> wrote:

Hi, Nirbhay!

On Jun 08, Nirbhay Choubey wrote:

...

revision-id: 7948cc32b6c12c9696e8b497ae90f123cafcd234 parent(s): 6d5b723bdc3e04978619b9673fca266e0426916f committer: Nirbhay Choubey branch nick: 10.0-galera.ctas timestamp: 2015-06-08 22:50:26 -0400 message:

MDEV-8260 : Issues related to concurrent CTAS

* Wait for aborted thd (victim) to release MDL locks * Skip aborting an already aborted thd * Defer setting OK status in case of CTAS * Minor cosmetic changes * Added a test case ... +bool select_insert::send_eof() +{ + DBUG_ENTER("select_insert::send_eof"); + DBUG_RETURN(prepare_eof() || send_ok_packet()); }

Please, don't do that, don't put function calls in DBUG_RETURN. This will result in dbug traces like

...

select_insert::send_eof < select_insert::send_eof select_insert::prepare_eof < select_insert::prepare_eof select_insert::send_ok_packet < select_insert::send_ok_packet

while the correct trace should've be

...

select_insert::send_eof | > select_insert::prepare_eof | < select_insert::prepare_eof | > select_insert::send_ok_packet | < select_insert::send_ok_packet < select_insert::send_eof

Wow.. that's interesting.

So, either write like

bool res= prepare_eof() || send_ok_packet(); DBUG_RETURN(res);

or fix DBUG_RETURN() macro. Whatever you prefer :)

I would prefer not to offset DBUG macros at least for now. :)

Otherwise the patch is ok.

http://lists.askmonty.org/pipermail/commits/2015-June/008029.html Thanks! -- Nirbhay

Regards, Sergei