1. 27 Sep, 2022 1 commit
  2. 26 Sep, 2022 6 commits
  3. 23 Sep, 2022 1 commit
    • Andrew Hutchings's avatar
      MDEV-25767 Fix CONNECT ODBC WHERE condition crash (#2243) · 66cd1c33
      Andrew Hutchings authored
      When an UPDATE or DELETE was executed with a WHERE condition it would
      crash the MariaDB server. This is because the code expects the WHERE
      condition to have generated a query string but it hasn't.
      
      Also updates the ODBC test results for current MariaDB version.
      66cd1c33
  4. 22 Sep, 2022 2 commits
  5. 21 Sep, 2022 2 commits
    • Alexey Botchkov's avatar
      Backport fix for MDEV-29352 to 10.3-10.5 · f5e4e154
      Alexey Botchkov authored
      The fix for MDEV-29352 was pushed to 10.6+ but the code causing the
      bug is old and the bug is unlikely to be a recent regression in 10.6.
      So, we apply the fix also to older versions, 10.3-10.5.
      
      The original commit message:
      
      MDEV-29352 SIGSEGV's in strlen and unknown location on optimized builds at SHUTDOWN
      
      When the UDF creation frails to write the newly created UDF into
      the related system table, the UDF is still created in memory.
      
      However, as it is now, the related DLL is unloaded in this case right
      in the mysql_create_function. And failure happens when the UDF handle
      is freed and tries to unload the respective DLL which is still unloaded.
      f5e4e154
    • Ian Gilfillan's avatar
      MDEV-29275 Fix server/Docs typos · b9c1c07f
      Ian Gilfillan authored
      b9c1c07f
  6. 20 Sep, 2022 3 commits
    • Brandon Nesterenko's avatar
      MDEV-28986: rpl tests sometimes failing on freebsd builders · b6bf7cd1
      Brandon Nesterenko authored
      The rpl_row_img_sequence test can fail on resource
      constrained buildbot machines due to its high
      space consumption. To reduce this footprint, the
      test is split into three parts, one for each value
      of the binlog_row_img variable.
      b6bf7cd1
    • Sergei Golubchik's avatar
      MDEV-29480 spider group by handler wrong result on order by aggregate alias · fc8a7655
      Sergei Golubchik authored
      when generating a query to send to a remote server, spider generates
      new aliases for all tables in the query (at least in the group_by handler).
      First it walks all the expressions and create a list of new table aliases
      to use for each field. Then - in init_scan() - it actually generates the
      query, taking for each field the next alias from the list.
      
      It dives recursively into functions, for example, for func(f1) it'll
      go in, will see the field f1 and append to the list the new name for
      the table of f1. This works fine for non-aggregate functions and
      for aggregate functions in the SELECT list. But aggregate functions
      in the ORDER BY are always references to the select list, they never
      need to be qualified with a table name. That is, even if there is a
      field name as an argument of an aggregate function in the ORDER BY
      it must not append a table alias to the list. Let's just skip
      aggregate functions when analyzing ORDER BY for table aliases.
      
      This fixes spider/bugfix.mdev_29008
      (was observed on aarch64, x86, ppc64le, and amd64 --rr)
      fc8a7655
    • Alexander Barkov's avatar
  7. 19 Sep, 2022 7 commits
  8. 15 Sep, 2022 1 commit
  9. 14 Sep, 2022 7 commits
    • Sergei Golubchik's avatar
      MDEV-22647 Assertion `!check_audit_mask(mysql_global_audit_mask, event_class_mask)' · beffef9f
      Sergei Golubchik authored
      
      check_audit_mask(mysql_global_audit_mask, event_class_mask) is tested in
      mysql_audit_general_log() and then assert in mysql_audit_acquire_plugins()
      verifies that the condition still holds.
      But this code path is not protected by LOCK_audit_mask, so
      mysql_global_audit_mask can change its value between the if() and the
      assert. That is, the assert is invalid and will fire if the
      audit plugin is unloaded concurrently with mysql_audit_general_log().
      
      Nothing bad will happen in this case though, we'll just do a useless
      loop over all remaining installed audit plugins.
      
      That is, the fix is simply to remove the assert.
      beffef9f
    • Anel Husakovic's avatar
      Add missing comment and remove unnecessary initialization · b7928f75
      Anel Husakovic authored
      - Commit c8948b0d introduced `get_one_variable()` - updating missing argument.
      - Remove caller setting of empty string in `rpl_filter`, since underlying functions will do the same
        (commit 9584cbe7 introduced).
      
      Reviewed by: <brandon.nesterenko@mariadb.com>
      b7928f75
    • Vicențiu Ciorbaru's avatar
      MDEV-29509 execute granted indirectly (via roles) doesn't always work · 16b2bb90
      Vicențiu Ciorbaru authored
      The issue manifests due to a bug in mysql_routine_grant. This was a side
      effect of e46eea86 which fixed the problem of not giving appropriate error
      message (ER_NONEXISTING_PROC_GRANT) when a routine grant existed due to role
      inheritance.
      
      When granting a routine privilege, it is possible to have a GRANT_NAME
      entry already created from an inherited role, but with it's init_privs
      set to 0.
      
      In this case we must not create a *new* grant entry, but we must edit
      this grant entry to set its init_privs.
      
      Note that this case was already covered by MDEV-29458, however due to a
      forgotten "flush privileges;" the actual code path never got hit.
      Remove the flush privilege command as it was never intended to be there
      in the first place.
      16b2bb90
    • Vicențiu Ciorbaru's avatar
      5ad8cd93
    • Vicențiu Ciorbaru's avatar
      MDEV-29458: Role grant commands do not propagate all grants · 7735ba76
      Vicențiu Ciorbaru authored
      There was an issue in updating in-memory role datastructures when
      propagating role grants.
      
      The issue is that changing a particular role's privilege (on any
      privilege level, global, database, etc.)
      was done such that it overwrote the entire set of bits for that
      particular level of privileges.
      
      For example:
      grant select on *.* to r1 -> sets the access bits to r1 to select,
      regardless of what bits were present for role r1 (inherited from any
      other roles).
      
      Before this fix, the rights of role r1 were propagated to any roles r1
      was granted to, however the propagated rights did *not* include the
      complete rights r1 inherited from its own grants.
      
      For example:
        grant r2 to r1;
        grant select on *.* to r2;
        grant insert on *.* to r1; # This command completely disregards the
                                   # select privilege from r2.
      
      In order to correct this, ensure that before rights are propagated
      onwards, that the current's role rights have been updated from its
      grants.
      
      Additionally, the patch exposed a flaw in the DROP ROLE code.
      When deleting a role we removed all its previous grants, but what
      remained was the actual links of roles granted to the dropped role.
      Having these links present when propagating grants meant that we would
      have leftover ACL_xxx entries.
      
      Ensure that the links are removed before propagating grants.
      7735ba76
    • Vicențiu Ciorbaru's avatar
      MDEV-29465: Inherited columns privs for roles wrongly set mysql.tables_priv column · 145932a5
      Vicențiu Ciorbaru authored
      There was a bug in the ACL internal data structures GRANT_TABLE and
      GRANT_COLUMN. The semantics are: GRANT_TABLE::init_cols and
      GRANT_COLUMN::init_privs represent the bits that correspond to the
      privilege bits stored in the physical tables. The other struct members
      GRANT_TABLE::cols and GRANT_COLUMN::privs represent the actual access
      bits, as they may be modified through role grants.
      
      The error in logic was mixing the two fields and thus we ended up
      storing the logical access bits in the physical tables, instead of the
      physical (init_xxx) bits.
      
      This caused subsequent DBUG_ASSERT failures when dropping the involved
      roles.
      145932a5
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-29479 I_S.INNODB_SYS_TABLESPACES doesn't have temporary tablespace information · d7aefc0f
      Thirunarayanan Balathandayuthapani authored
      - innodb_sys_tablespaces view in information schema displays temporary
      tablespace information too.
      d7aefc0f
  10. 13 Sep, 2022 5 commits
  11. 12 Sep, 2022 2 commits
  12. 08 Sep, 2022 1 commit
  13. 07 Sep, 2022 1 commit
    • Tuukka Pasanen's avatar
      MDEV-28605: Change wrong plugin config installation location (#2160) · 04899d6d
      Tuukka Pasanen authored
      Preset include directory for configuration files below MariaDB 10.5 is
      /etc/mysql/conf.d
      
      Change installation location wrong plugin installation location from
      /etc/mysql/mariadb.d to default include directory /etc/mysql/conf.d.
      Change makes gssapi-server, oqgraph, rocksdb and tokudb plugins
      loading work after installation
      
      NOTE TO MERGERS: This commit should be upstream to MariaDB 10.4 only!
      Merging to MariaDB 10.5 and above leads to major problems.
      04899d6d
  14. 06 Sep, 2022 1 commit