1. 06 May, 2017 3 commits
  2. 05 May, 2017 5 commits
  3. 04 May, 2017 8 commits
  4. 03 May, 2017 4 commits
    • Igor Babaev's avatar
      Fixed the bug mdev-11990. · ce8ee7d9
      Igor Babaev authored
      The usage of windows functions when all tables were optimized away
      by min/max optimization were not supported. As result a result,
      the queries that used window functions with min/max aggregation
      over the whole table returned wrong result sets.
      The patch fixed this problem.
      ce8ee7d9
    • halfspawn's avatar
    • Alexander Barkov's avatar
      Adding Item_func_pad as a common parent for Item_func_lpad and Item_func_rpad · 736a1d29
      Alexander Barkov authored
      Removing duplication:
      - fix_length_and_dec()
      - tmp_value
      - lpad_str, rpad_str -> pad_str
      736a1d29
    • Daniel Black's avatar
      MDEV-12469: rocksdb having large numberic storage errors on ppc64 (BE) · 52463ccf
      Daniel Black authored
      (from: http://buildbot.askmonty.org/buildbot/builders/p8-rhel6-bintar/builds/820/steps/test/logs/stdio)
      
      Errors like the following indicate a potential endian storage issue:
      
      rocksdb.rocksdb_range                    w1 [ fail ]
              Test ended at 2017-04-27 18:56:11
      
      CURRENT_TEST: rocksdb.rocksdb_range
      --- /home/buildbot/maria-slave/p8-rhel6-bintar/build/storage/rocksdb/mysql-test/rocksdb/r/rocksdb_range.result	2017-04-27 17:41:27.740050347 -0400
      +++ /home/buildbot/maria-slave/p8-rhel6-bintar/build/storage/rocksdb/mysql-test/rocksdb/r/rocksdb_range.reject	2017-04-27 18:56:11.230050346 -0400
      @@ -25,15 +25,15 @@
       select * from t2 force index (a) where a=0;
       pk	a	b
       0	0	0
      -1	0	1
      -2	0	2
      -3	0	3
      -4	0	4
      -5	0	5
      -6	0	6
      -7	0	7
      -8	0	8
      -9	0	9
      +16777216	0	1
      +33554432	0	2
      +50331648	0	3
      +67108864	0	4
      +83886080	0	5
      +100663296	0	6
      +117440512	0	7
      +134217728	0	8
      +150994944	0	9
       # The rest are for code coverage:
       explain
       select * from t2 force index (a) where a=2;
      @@ -41,23 +41,23 @@
       1	SIMPLE	t2	ref	a	a	4	const	#
       select * from t2 force index (a) where a=2;
       pk	a	b
      -20	2	20
      -21	2	21
      -22	2	22
      -23	2	23
      -24	2	24
      -25	2	25
      -26	2	26
      -27	2	27
      -28	2	28
      -29	2	29
      +335544320	2	20
      +352321536	2	21
      +369098752	2	22
      +385875968	2	23
      +402653184	2	24
      +419430400	2	25
      +436207616	2	26
      +452984832	2	27
      +469762048	2	28
      +486539264	2	29
       explain
       select * from t2 force index (a) where a=3 and pk=33;
       id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
       1	SIMPLE	t2	const	a	a	8	const,const	#
       select * from t2 force index (a) where a=3 and pk=33;
       pk	a	b
      -33	3	33
      +553648128	3	33
       select * from t2 force index (a) where a=99 and pk=99;
       pk	a	b
       select * from t2 force index (a) where a=0 and pk=0;
      ...
      Signed-off-by: default avatarDaniel Black <daniel.black@au.ibm.com>
      52463ccf
  5. 02 May, 2017 10 commits
  6. 01 May, 2017 1 commit
  7. 30 Apr, 2017 5 commits
  8. 29 Apr, 2017 2 commits
    • Alexander Barkov's avatar
    • Igor Babaev's avatar
      Fixed the bug mdev-12563. · 7a29ca27
      Igor Babaev authored
      The bug happened when the specification of a recursive CTE had
      no recursive references at the top level of the specification.
      In this case the regular processing of derived table references
      of the select containing a non-recursive reference to this
      recursive CTE misses handling the specification unit.
      At the preparation stage any non-recursive reference to a
      recursive CTE must be handled after the preparation of the
      specification unit for this CTE. So we have to force this
      preparation when regular handling of derived tables does not
      do it.
      7a29ca27
  9. 28 Apr, 2017 2 commits
    • Alexander Barkov's avatar
    • Marko Mäkelä's avatar
      MDEV-12602 InnoDB: Failing assertion: space->n_pending_ops == 0 · 4b24467f
      Marko Mäkelä authored
      This fixes a regression caused by MDEV-12428.
      When we introduced a variant of fil_space_acquire() that could
      increment space->n_pending_ops after space->stop_new_ops was set,
      the logic of fil_check_pending_operations() was broken.
      
      fil_space_t::n_pending_ios: A new field to track read or write
      access from the buffer pool routines immediately before a block
      write or after a block read in the file system.
      
      fil_space_acquire_for_io(), fil_space_release_for_io(): Similar
      to fil_space_acquire_silent() and fil_space_release(), but
      modify fil_space_t::n_pending_ios instead of fil_space_t::n_pending_ops.
      
      fil_space_free_low(): Wait for space->n_pending_ios to reach 0,
      to avoid accessing freed data in a concurrent thread. Future
      calls to fil_space_acquire_for_io() will not find this tablespace,
      because it will already have been detached from fil_system.
      
      Adjust a number of places accordingly, and remove some redundant
      tablespace lookups.
      
      FIXME: buf_page_check_corrupt() should take a tablespace from
      fil_space_acquire_for_io() as a parameter. This will be done
      in the 10.1 version of this patch and merged from there.
      That depends on MDEV-12253, which has not been merged from 10.1 yet.
      4b24467f