1. 19 May, 2020 1 commit
  2. 18 May, 2020 2 commits
  3. 15 May, 2020 1 commit
    • Alexander Barkov's avatar
      MDEV-22579 No error when inserting DEFAULT(non_virtual_column) into a virtual column · 3df29727
      Alexander Barkov authored
      The code erroneously allowed both:
      INSERT INTO t1 (vcol) VALUES (DEFAULT);
      INSERT INTO t1 (vcol) VALUES (DEFAULT(non_virtual_column));
      
      The former is OK, but the latter is not.
      Adding a new virtual method in Item:
      
      virtual bool vcol_assignment_allowed_value() const { return false; }
      
      Item_null, Item_param and Item_default_value override it.
      
      Item_default_value overrides it in the way to:
      - allow DEFAULT
      - disallow DEFAULT(col)
      3df29727
  4. 14 May, 2020 4 commits
  5. 11 May, 2020 2 commits
  6. 08 May, 2020 3 commits
  7. 07 May, 2020 1 commit
    • Marko Mäkelä's avatar
      MDEV-22497 [ERROR] InnoDB: Unable to purge a record · 26aab96e
      Marko Mäkelä authored
      The InnoDB insert buffer was upgraded in MySQL 5.5 into a change
      buffer that also covers delete-mark and delete (purge) operations.
      
      There is an important constraint for delete operations: a B-tree
      leaf page must not become empty unless the entire tree becomes empty,
      consisting of an empty root page. Because change buffer merges only
      occur on a single leaf page at a time, delete operations must not be
      buffered if it is possible that the last record of the page could be
      deleted. (In that case, we would refuse to use the change buffer, and
      if we really delete the last record, we would shrink the index tree.)
      
      The function ibuf_get_volume_buffered_hash() is part of our insurance
      that the page would not become empty. It is supposed to map each
      buffered INSERT or DELETE_MARK record payload into a hash value.
      We will only count each such record as a distinct key if there is no
      hash collision. DELETE operations will always decrement the predicted
      number fo records in the page.
      
      Due to a bug in the function, we would actually compute the hash value
      not only on the record payload, but also on some following bytes,
      in case the record contains NULL values. In MySQL Bug #61104, we had
      some examples of this dating back to 2012. But back then, we failed to
      reproduce the bug, and in commit d84c9557
      we simply demoted the hard assertion to a message printout and a debug
      assertion failure.
      
      ibuf_get_volume_buffered_hash(): Correctly compute the hash value
      of the payload bytes only. Note: we will consider
      ('foo','bar'),(NULL,'foobar'),('foob','ar') to be equal, but this
      is not a problem, because in case of a hash collision, we could
      also consider ('boo','far') to be equal, and underestimate the number
      of records in the page, leading to refusing to buffer a DELETE.
      26aab96e
  8. 06 May, 2020 6 commits
  9. 05 May, 2020 2 commits
  10. 04 May, 2020 4 commits
  11. 30 Apr, 2020 12 commits
  12. 29 Apr, 2020 2 commits