Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-5600

Wrong result on 2nd execution of PS depending on the length of the query

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 5.3.12, 5.5.35, 10.0.8
    • 5.5.36, 10.0.9, 5.3.13
    • None
    • None

    Description

      This is the problem briefly discussed with Monty on IRC, when the result of the 2nd execution depends on seemingly unimportant factors. I will collect all information that I have so that it's not forgotten, but I suggest to put it aside till more pressing tasks are finished. It would be good to investigate it though, as it's one of things which are impossible to analyze when it happens in external users' environment.

      Assorted notes and observations:

      • the result depends even on insignificant blank spaces in the query (a few less of those and the failure is gone), name of the basedir, etc.
      • I could reproduce it on at least two different machines (Ubuntu Precise 64-bit and Debian Wheezy 64-bit), so it's not limited to the machine or particular OS flavor;
      • I could reproduce it via MySQL client, although it required some additional seemingly useless actions, so it's not limited to MTR either;
      • the result seems persistent within the same machine, same build, but it might be different on different machines (the query that causes a failure on one machine did not do the same on the other at first, I had to revert to a little longer query to make the bug re-appear on the 2nd machine);
      • the problem appears at least with at least BUILD/compile-pentium-debug-max-no-ndb builds;
      • the problem is reproducible with -mysqld=-debug;
      • the problem stops appearing if the test is run with --valgrind-mysqld;
      • I could reproduce it on 5.3 (current tree) and on 5.3.12; could not reproduce on 5.5 so far, but due to the fragility of the test case it does not mean that it does not exist in 5.5.

      Two complete test cases with the data are attached, mdev5600_bad.test and mdev5600_good.test. They only differ by one space in the query (where 3 right brackets come in a row):

      SELECT alias2 . `col_time_key` AS field1, MIN(alias1 . `col_int_key`) AS field2, alias1.`col_int_nokey` AS field3, alias1.`col_varchar_key` AS field4 , MIN(alias1.`col_varchar_nokey` ) AS field5, alias1.`col_time_key` AS field6,  ( SELECT MAX( DISTINCT SQ1_alias1.`col_varchar_nokey` ) AS SQ1_field1 FROM CC AS SQ1_alias1 ) AS field7 FROM ( CC AS alias1, C AS alias2, ( SELECT SQL_SMALL_RESULT SQ2_alias1.* FROM ( C AS SQ2_alias1 STRAIGHT_JOIN D AS SQ2_alias2 ON (SQ2_alias2.`pk` = SQ2_alias1.`col_int_nokey` ) ) ) AS alias3 ) WHERE ( alias3.`col_int_key`, alias3 . `col_int_key` ) IN ( SELECT   SQ3_alias1 . `col_int_nokey` AS SQ3_field1 , SQ3_alias1 . `pk` AS SQ3_field2 FROM ( C AS SQ3_alias1 INNER JOIN C AS SQ3_alias2 ON (SQ3_alias2 . `col_int_key` = SQ3_alias1 . `col_int_key`  ) )    )  GROUP BY field1, field3, field4, field6, field7  ORDER BY alias1 . `col_time_key` ASC , field1, field2, field3, field4, field5, field6, field7
       
      SELECT alias2 . `col_time_key` AS field1, MIN(alias1 . `col_int_key`) AS field2, alias1.`col_int_nokey` AS field3, alias1.`col_varchar_key` AS field4 , MIN(alias1.`col_varchar_nokey` ) AS field5, alias1.`col_time_key` AS field6,  ( SELECT MAX( DISTINCT SQ1_alias1.`col_varchar_nokey` ) AS SQ1_field1 FROM CC AS SQ1_alias1 ) AS field7 FROM ( CC AS alias1, C AS alias2, ( SELECT SQL_SMALL_RESULT SQ2_alias1.* FROM ( C AS SQ2_alias1 STRAIGHT_JOIN D AS SQ2_alias2 ON (SQ2_alias2.`pk` = SQ2_alias1.`col_int_nokey` ) ) ) AS alias3 ) WHERE ( alias3.`col_int_key`, alias3 . `col_int_key` ) IN ( SELECT   SQ3_alias1 . `col_int_nokey` AS SQ3_field1 , SQ3_alias1 . `pk` AS SQ3_field2 FROM ( C AS SQ3_alias1 INNER JOIN C AS SQ3_alias2 ON (SQ3_alias2 . `col_int_key` = SQ3_alias1 . `col_int_key`  ) )   )  GROUP BY field1, field3, field4, field6, field7  ORDER BY alias1 . `col_time_key` ASC , field1, field2, field3, field4, field5, field6, field7

      The first query on the 2nd execution as a PS returns an empty set. The second one returns a result set.

      The test is very unclean, with ugly names and probably excessive data, but I cannot safely clean it up due to the nature of the problem.

      I ran the bad and good tests with debug, extracted the fragments that belong to the 2nd execution, converted them using convert-dbug-for-diff and attached the diff as mdev5600_trace_diff_between_bad_and_good. In case it did not go right there are also compressed full trace files, mdev5600_bad.trace.gz and mdev5600_bad.trace.gz (also uploaded to hasky:/tmp).

      I have also set up the test on perro under mdev5600 folder.

      cd mdev5600/mysql-test

      Indication of the good result (it's the tail of the result set from the 2nd execution, followed by DROP):

      perl ./mtr mdev5600_good
      ...
      18:56:33	8	NULL	x	x	22:55:23	y
      19:11:10	8	NULL	x	x	22:55:23	y
      22:34:09	8	NULL	x	x	22:55:23	y
      DROP TABLE IF EXISTS C, D, CC;

      Indication of the bad result (it's the tail of the result set from the 1nd execution, followed by the second EXECUTE with an empty result set, followed by DROP):

      perl ./mtr mdev5600_bad
      ...
      18:56:33	8	NULL	x	x	22:55:23	y
      19:11:10	8	NULL	x	x	22:55:23	y
      22:34:09	8	NULL	x	x	22:55:23	y
      EXECUTE stmt;
      field1	field2	field3	field4	field5	field6	field7
      DROP TABLE IF EXISTS C, D, CC;

      Attachments

        Activity

          It's equality propagation code. When trying to do equality substitution for
          (gdb) p dbug_print_item(ref_item)
          $769 = 0x153ca20 "`j23`.`SUBQUERY1_t1`.`col_int_nokey`"

          the second execution sees and makes use of:

          multiple equal(`j44`.`SUBQUERY1_t1`.`col_varchar_nokey`, `j44`.`table3`.`col_varchar_key`)

          while the first execution doesn't see it.

          Hmm.. how come this multi-quality is used for substituting col_int_nokey? It doesn't include col_int_nokey...

          psergei Sergei Petrunia added a comment - It's equality propagation code. When trying to do equality substitution for (gdb) p dbug_print_item(ref_item) $769 = 0x153ca20 "`j23`.`SUBQUERY1_t1`.`col_int_nokey`" the second execution sees and makes use of: multiple equal(`j44`.`SUBQUERY1_t1`.`col_varchar_nokey`, `j44`.`table3`.`col_varchar_key`) while the first execution doesn't see it. Hmm.. how come this multi-quality is used for substituting col_int_nokey? It doesn't include col_int_nokey...

          Hardware watchpoint 35: *$a4
          Old value = (Item_equal *) 0x0
          New value = (Item_equal *) 0x7fffcd130078

          field_item->set_item_equal(item_equal);

          (gdb) p dbug_print_item(field_item)
          $1407 = 0x153ba20 "`j44`.`SUBQUERY1_t1`.`col_int_nokey`"
          (gdb) p dbug_print_item(item_equal)
          $1409 = 0x153ba20 "multiple equal(`j44`.`SUBQUERY1_t1`.`col_varchar_nokey`, `j44`.`table3`.`col_varchar_key`)"

          So, an Item_field gets a wrong Item_equal. It happens here:

          #0 0x00000000007f8917 in Item_field::set_item_equal
          #1 0x00000000007f24f4 in Item_direct_view_ref::replace_equal_field
          #2 0x00000000007ef53a in Item_ref::transform
          #3 0x000000000066089e in substitute_for_best_equal_field
          #4 0x0000000000643895 in JOIN::optimize
          #5 0x00000000006499cd in mysql_select

          psergei Sergei Petrunia added a comment - Hardware watchpoint 35: *$a4 Old value = (Item_equal *) 0x0 New value = (Item_equal *) 0x7fffcd130078 field_item->set_item_equal(item_equal); (gdb) p dbug_print_item(field_item) $1407 = 0x153ba20 "`j44`.`SUBQUERY1_t1`.`col_int_nokey`" (gdb) p dbug_print_item(item_equal) $1409 = 0x153ba20 "multiple equal(`j44`.`SUBQUERY1_t1`.`col_varchar_nokey`, `j44`.`table3`.`col_varchar_key`)" So, an Item_field gets a wrong Item_equal. It happens here: #0 0x00000000007f8917 in Item_field::set_item_equal #1 0x00000000007f24f4 in Item_direct_view_ref::replace_equal_field #2 0x00000000007ef53a in Item_ref::transform #3 0x000000000066089e in substitute_for_best_equal_field #4 0x0000000000643895 in JOIN::optimize #5 0x00000000006499cd in mysql_select

          So, we are at
          #1 0x000000000066089e in substitute_for_best_equal_field (context_tab=0x7fffcd1340c8, cond=0x7fffcd053db8, cond_equal=0x7fffcd047568, table_join_idx=0x7fffcd130ea0) at /home/psergey/dev2/5.5/sql/sql_select.cc:12615
          (gdb) wher
          #0 Item_ref::transform (this=0x7fffcd053db8, transformer=&virtual Item::replace_equal_field(unsigned char*), arg=0x7ffff7eea710 "\330\213\004\315\377\177") at /home/psergey/dev2/5.5/sql/item.cc:7104
          #1 0x000000000066089e in substitute_for_best_equal_field (context_tab=0x7fffcd1340c8, cond=0x7fffcd053db8, cond_equal=0x7fffcd047568, table_join_idx=0x7fffcd130ea0) at /home/psergey/dev2/5.5/sql/sql_select.cc:12615
          #2 0x0000000000643895 in JOIN::optimize (this=0x7fffcd0477e8) at /home/psergey/dev2/5.5/sql/sql_select.cc:1362

          (gdb) p dbug_print_item(cond)
          $1446 = 0x153ba20 "`j44`.`SUBQUERY1_t1`.`col_int_nokey`"
          (gdb) p (Item*)cond
          $1447 = (Item_direct_view_ref *) 0x7fffcd053db8

          (gdb) p dbug_print_item(item_equal)
          $1448 = 0x153ba20 "multiple equal(`j44`.`SUBQUERY1_t1`.`col_int_nokey`, `j44`.`SUBQUERY2_t1`.`col_int_key`)"

          We enter Item_ref::transform. We execute this:

          . Item *new_item= (*ref)->transform(transformer, arg);

          which calls Item::transform() which calls Item_field::replace_equal_field().
          The condition

          . if (item_equal && item_equal == param->item_equal)

          fails because item_equal==NULL, and no substitution takes place.
          Item_ref::transform() invokes this:

          . return (this->*transformer)(arg);

          which calls Item_direct_view_ref::replace_equal_field, which runs

          field_item->set_item_equal(item_equal);

          psergei Sergei Petrunia added a comment - So, we are at #1 0x000000000066089e in substitute_for_best_equal_field (context_tab=0x7fffcd1340c8, cond=0x7fffcd053db8, cond_equal=0x7fffcd047568, table_join_idx=0x7fffcd130ea0) at /home/psergey/dev2/5.5/sql/sql_select.cc:12615 (gdb) wher #0 Item_ref::transform (this=0x7fffcd053db8, transformer=&virtual Item::replace_equal_field(unsigned char*), arg=0x7ffff7eea710 "\330\213\004\315\377\177") at /home/psergey/dev2/5.5/sql/item.cc:7104 #1 0x000000000066089e in substitute_for_best_equal_field (context_tab=0x7fffcd1340c8, cond=0x7fffcd053db8, cond_equal=0x7fffcd047568, table_join_idx=0x7fffcd130ea0) at /home/psergey/dev2/5.5/sql/sql_select.cc:12615 #2 0x0000000000643895 in JOIN::optimize (this=0x7fffcd0477e8) at /home/psergey/dev2/5.5/sql/sql_select.cc:1362 (gdb) p dbug_print_item(cond) $1446 = 0x153ba20 "`j44`.`SUBQUERY1_t1`.`col_int_nokey`" (gdb) p (Item*)cond $1447 = (Item_direct_view_ref *) 0x7fffcd053db8 (gdb) p dbug_print_item(item_equal) $1448 = 0x153ba20 "multiple equal(`j44`.`SUBQUERY1_t1`.`col_int_nokey`, `j44`.`SUBQUERY2_t1`.`col_int_key`)" We enter Item_ref::transform. We execute this: . Item *new_item= (*ref)->transform(transformer, arg); which calls Item::transform() which calls Item_field::replace_equal_field(). The condition . if (item_equal && item_equal == param->item_equal) fails because item_equal==NULL, and no substitution takes place. Item_ref::transform() invokes this: . return (this->*transformer)(arg); which calls Item_direct_view_ref::replace_equal_field, which runs field_item->set_item_equal(item_equal);

          Maybe, it's Item_direct_view_ref object that is participating in the wrong Item_equal.

          The problematic Item_direct_view_ref can be found as follows: put a
          breakpoint on Item_direct_view_ref::fix_fields, and note the first object
          for which the breakpoint is hit on the second EXECUTE statement.

          When the breakpoint is hit, Item_direct_view_ref::item_equal has non-zero
          value, but I suspect it is invalid data.

          psergei Sergei Petrunia added a comment - Maybe, it's Item_direct_view_ref object that is participating in the wrong Item_equal. The problematic Item_direct_view_ref can be found as follows: put a breakpoint on Item_direct_view_ref::fix_fields, and note the first object for which the breakpoint is hit on the second EXECUTE statement. When the breakpoint is hit, Item_direct_view_ref::item_equal has non-zero value, but I suspect it is invalid data.

          Ok, here it is how it goes:
          mysql> source q2.sql
          mysql> execute stmt;

          Breakpoint 29, Item_direct_view_ref::Item_direct_view_ref (this=0x7fffcd453db8, context_arg=0x7d8, item=0x7fffcd452120, table_name_arg=0x7fffcd463ff0 "table2", field_name_arg=0x7fffcd4513c8 "col_int_nokey", view_arg=0x7fffcd4e4d98) at /home/psergey/dev2/5.5/sql/item.h:3301

          Breakpoint 29, Item_direct_view_ref::Item_direct_view_ref ...

          Breakpoint 29, Item_direct_view_ref::Item_direct_view_ref ...

          Breakpoint 38, Item_equal::Item_equal (this=0x7fffcd530078, f1=0x7fffcd453db8, f2=0x7fffcd4e8a80, with_const_item=false) at /home/psergey/dev2/5.5/sql/item_cmpfunc.cc:5602
          // Note the f1, it matches the Irem_direct_view_ref above. This is a multi-equality that Item_ref will participate in.
          // Let's keep track of when this Item_equal is deleted:
          (gdb) b Item::delete_self
          Breakpoint 40 at 0x5e222c: file /home/psergey/dev2/5.5/sql/item.h, line 1396.
          (gdb) cond 40 (this ==0x7fffcd530078)

          // Let's also put a breakpoint somewhere in JOIN::optimize after equality propagation is done.
          (gdb) break "/home/psergey/dev2/5.5/sql/sql_select.cc:1149"
          Breakpoint 41 at 0x642bd7: file /home/psergey/dev2/5.5/sql/sql_select.cc, line 1149.

          (gdb) cont

          Breakpoint 38, Item_equal::Item_equal( .... // ignore this
          Breakpoint 38, Item_equal::Item_equal (... // ignore this

          Breakpoint 41, JOIN::optimize (this=0x7fffcd4478f0) at /home/psergey/dev2/5.5/sql/sql_select.cc:1149

          // Ok, let's see how our objects are doing

          (gdb) p ((Item_direct_view_ref*)0x7fffcd453db8)->item_equal
          $1622 = (Item_equal *) 0x7fffcd530078
          (gdb) p dbug_print_item(((Item_direct_view_ref*)0x7fffcd453db8)->item_equal)
          $1623 = 0x153ba20 "multiple equal(`j44`.`SUBQUERY1_t1`.`col_int_nokey`, `j44`.`SUBQUERY2_t1`.`col_int_key`)"
          (gdb) p dbug_print_item(((Item_direct_view_ref*)0x7fffcd453db8))
          $1624 = 0x153ba20 "`j44`.`SUBQUERY1_t1`.`col_int_nokey`"

          // Item_..._ref has pointer to Item_equal, and this seems to be correct ...

          (gdb) cont

          Breakpoint 40, Item::delete_self (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item.h:1396
          // Ok, this is Item_equal deleting himself...

          (gdb) p ((Item_direct_view_ref*)0x7fffcd453db8)->item_equal
          $1629 = (Item_equal *) 0x7fffcd530078
          // ^^^Note that Item_direct_view_ref object still has the wrong pointer.

          // Let's see if the item is created at that location:
          (gdb) b Item::Item
          Breakpoint 42 at 0x7dd866: Item::Item. (2 locations)
          (gdb) cond 42 (this == 0x7fffcd530078)
          (gdb) c

          (gdb) cont

          ----------

          COUNT

          ----------

          3

          ----------
          // First EXECUTE has finished.
          // Call it once again:
          mysql> execute stmt;

          ...
          Breakpoint 27, Item_direct_view_ref::fix_fields (this=0x7fffcd453db8, thd=0x7fffd3e7c060, reference=0x7fffcd52c058) at /home/psergey/dev2/5.5/sql/item.cc:7898
          // This is our Item_direct_view_ref...

          Breakpoint 38, Item_equal::Item_equal (this=0x7fffcd448bd8, f1=0x7fffcd453db8, f2=0x7fffcd4e8a80, with_const_item=false) at /home/psergey/dev2/5.5/sql/item_cmpfunc.cc:5602
          // This is the Item_equal that's made from for our Item_direct_view_ref

          Breakpoint 42, Item::Item (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item.cc:499
          // And this is another item that is created in the location that Item_direct_view_ref has pointer to...

          (gdb) up
          #1 0x00000000005752e4 in Item_result_field::Item_result_field (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item.h:2869
          (gdb) up
          #2 0x00000000005ec7f8 in Item_func::Item_func (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item_func.h:67
          (gdb) up
          #3 0x00000000005ecbc8 in Item_int_func::Item_int_func (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item_func.h:577
          (gdb) up
          #4 0x00000000005ecca6 in Item_bool_func::Item_bool_func (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item_cmpfunc.h:121
          (gdb) up
          #5 0x0000000000810155 in Item_equal::Item_equal (this=0x7fffcd530078, f1=0x7fffcd4e5a10, f2=0x7fffcd448940, with_const_item=false) at /home/psergey/dev2/5.5/sql/item_cmpfunc.cc:5602
          (gdb) p dbug_print_item(f1)
          $1642 = 0x153ba20 "`j44`.`table3`.`col_varchar_key`"
          (gdb) p dbug_print_item(f2)
          $1644 = 0x153ba20 "`j44`.`SUBQUERY1_t1`.`col_varchar_nokey`"

          THis is how the Item_direct_view_ref, which represents a reference to col_int_nokey column gets connected to col_varchar*key column.

          psergei Sergei Petrunia added a comment - Ok, here it is how it goes: mysql> source q2.sql mysql> execute stmt; Breakpoint 29, Item_direct_view_ref::Item_direct_view_ref (this=0x7fffcd453db8, context_arg=0x7d8, item=0x7fffcd452120, table_name_arg=0x7fffcd463ff0 "table2", field_name_arg=0x7fffcd4513c8 "col_int_nokey", view_arg=0x7fffcd4e4d98) at /home/psergey/dev2/5.5/sql/item.h:3301 Breakpoint 29, Item_direct_view_ref::Item_direct_view_ref ... Breakpoint 29, Item_direct_view_ref::Item_direct_view_ref ... Breakpoint 38, Item_equal::Item_equal (this=0x7fffcd530078, f1=0x7fffcd453db8, f2=0x7fffcd4e8a80, with_const_item=false) at /home/psergey/dev2/5.5/sql/item_cmpfunc.cc:5602 // Note the f1, it matches the Irem_direct_view_ref above. This is a multi-equality that Item_ref will participate in. // Let's keep track of when this Item_equal is deleted: (gdb) b Item::delete_self Breakpoint 40 at 0x5e222c: file /home/psergey/dev2/5.5/sql/item.h, line 1396. (gdb) cond 40 (this ==0x7fffcd530078) // Let's also put a breakpoint somewhere in JOIN::optimize after equality propagation is done. (gdb) break "/home/psergey/dev2/5.5/sql/sql_select.cc:1149" Breakpoint 41 at 0x642bd7: file /home/psergey/dev2/5.5/sql/sql_select.cc, line 1149. (gdb) cont Breakpoint 38, Item_equal::Item_equal( .... // ignore this Breakpoint 38, Item_equal::Item_equal (... // ignore this Breakpoint 41, JOIN::optimize (this=0x7fffcd4478f0) at /home/psergey/dev2/5.5/sql/sql_select.cc:1149 // Ok, let's see how our objects are doing (gdb) p ((Item_direct_view_ref*)0x7fffcd453db8)->item_equal $1622 = (Item_equal *) 0x7fffcd530078 (gdb) p dbug_print_item(((Item_direct_view_ref*)0x7fffcd453db8)->item_equal) $1623 = 0x153ba20 "multiple equal(`j44`.`SUBQUERY1_t1`.`col_int_nokey`, `j44`.`SUBQUERY2_t1`.`col_int_key`)" (gdb) p dbug_print_item(((Item_direct_view_ref*)0x7fffcd453db8)) $1624 = 0x153ba20 "`j44`.`SUBQUERY1_t1`.`col_int_nokey`" // Item_..._ref has pointer to Item_equal, and this seems to be correct ... (gdb) cont Breakpoint 40, Item::delete_self (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item.h:1396 // Ok, this is Item_equal deleting himself... (gdb) p ((Item_direct_view_ref*)0x7fffcd453db8)->item_equal $1629 = (Item_equal *) 0x7fffcd530078 // ^^^Note that Item_direct_view_ref object still has the wrong pointer. // Let's see if the item is created at that location: (gdb) b Item::Item Breakpoint 42 at 0x7dd866: Item::Item. (2 locations) (gdb) cond 42 (this == 0x7fffcd530078) (gdb) c (gdb) cont ---------- COUNT ---------- 3 ---------- // First EXECUTE has finished. // Call it once again: mysql> execute stmt; ... Breakpoint 27, Item_direct_view_ref::fix_fields (this=0x7fffcd453db8, thd=0x7fffd3e7c060, reference=0x7fffcd52c058) at /home/psergey/dev2/5.5/sql/item.cc:7898 // This is our Item_direct_view_ref... Breakpoint 38, Item_equal::Item_equal (this=0x7fffcd448bd8, f1=0x7fffcd453db8, f2=0x7fffcd4e8a80, with_const_item=false) at /home/psergey/dev2/5.5/sql/item_cmpfunc.cc:5602 // This is the Item_equal that's made from for our Item_direct_view_ref Breakpoint 42, Item::Item (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item.cc:499 // And this is another item that is created in the location that Item_direct_view_ref has pointer to... (gdb) up #1 0x00000000005752e4 in Item_result_field::Item_result_field (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item.h:2869 (gdb) up #2 0x00000000005ec7f8 in Item_func::Item_func (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item_func.h:67 (gdb) up #3 0x00000000005ecbc8 in Item_int_func::Item_int_func (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item_func.h:577 (gdb) up #4 0x00000000005ecca6 in Item_bool_func::Item_bool_func (this=0x7fffcd530078) at /home/psergey/dev2/5.5/sql/item_cmpfunc.h:121 (gdb) up #5 0x0000000000810155 in Item_equal::Item_equal (this=0x7fffcd530078, f1=0x7fffcd4e5a10, f2=0x7fffcd448940, with_const_item=false) at /home/psergey/dev2/5.5/sql/item_cmpfunc.cc:5602 (gdb) p dbug_print_item(f1) $1642 = 0x153ba20 "`j44`.`table3`.`col_varchar_key`" (gdb) p dbug_print_item(f2) $1644 = 0x153ba20 "`j44`.`SUBQUERY1_t1`.`col_varchar_nokey`" THis is how the Item_direct_view_ref, which represents a reference to col_int_nokey column gets connected to col_varchar*key column.

          People

            psergei Sergei Petrunia
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.