1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-04 01:23:45 +03:00
Commit Graph

172 Commits

Author SHA1 Message Date
299b935320 MDEV-23908: Implement SELECT ... OFFSET ... FETCH ...
This commit implements the standard SQL extension
OFFSET start { ROW | ROWS }
[FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } { ONLY | WITH TIES }]

To achieve this a reserved keyword OFFSET is introduced.

The general logic for WITH TIES implies:
1. The number of rows a query returns is no longer known during optimize
   phase. Adjust optimizations to no longer consider this.
2. During end_send make use of an "order Cached_item"to compare if the
   ORDER BY columns changed. Keep returning rows until there is a
   change. This happens only after we reached the row limit.
3. Within end_send_group, the order by clause was eliminated. It is
   still possible to keep the optimization of using end_send_group for
   producing the final result set.
2021-04-21 14:09:14 +03:00
a3099a3b4a MDEV-24312 master_host has 60 character limit, increase to 255 bytes
Also increase user name up to 128.

The work was started by Rucha Deodhar <rucha.deodhar@mariadb.com>,
contains audit plugin fixes by Alexey Botchkov <holyfoot@askmonty.org>.
2021-04-20 16:36:56 +02:00
a4b7232b2c Merge 10.4 into 10.5 2021-03-11 20:09:34 +02:00
363ba10784 MDEV-24363 mysql.user password_expired column is incorrect
The mysql.user view password_expired column should display the right
result, in sync with whether an account has its password expired or not

For mariadb 10.4+ upgrades before this commit, the mysql.user view needs
to be dropped and recreated to actually make the view display the
correct value for the password_expired column.
2021-03-08 12:07:06 +02:00
50a11f396a Merge 10.4 into 10.5 2020-08-01 14:42:51 +03:00
153cd6a27f MDEV-23237 mariadb.sys has too many privileges
don't GRANT UPDATE ON mysql.global_priv TO mariadb.sys@localhost;
2020-07-31 09:00:05 +02:00
af27f17ea1 Merge 10.4 into 10.5 2020-07-13 17:05:13 +03:00
0d6d801e58 MDEV-23102 10.4 create mariadb.sys user on each update even is the user is not needed
Check if we really need the mariadb.sys user
2020-07-08 13:10:07 +02:00
13038e4705 Merge branch '10.4' into 10.5 2020-05-09 20:43:36 +02:00
0253ea7f22 MDEV-19650: Privilege bug on MariaDB 10.4
Also fixes:
MDEV-21487: Implement option for mysql_upgrade that allows root@localhost to be replaced
MDEV-21486: Implement option for mysql_install_db that allows root@localhost to be replaced

Add user mariadb.sys to be definer of user view
(and has right on underlying table global_priv for
required operation over global_priv
(SELECT,UPDATE,DELETE))

Also changed definer of gis functions in case of creation,
but they work with any definer so upgrade script do not try
to push this change.
2020-05-07 10:54:56 +02:00
45bc7574fb MDEV-18650: Options deprecated in previous versions - storage_engine
Remove usage of deprecated variable storage_engine. It was deprecated in 5.5 but
it never issued a deprecation warning. Make it issue a warning in 10.5.1.

Replaced with default_storage_engine.
2020-02-13 13:42:01 +02:00
5a92ccbaea Merge 10.3 into 10.4
Disable MDEV-20576 assertions until MDEV-20595 has been fixed.
2019-09-23 17:35:29 +03:00
c016ea660e Merge 10.2 into 10.3 2019-09-23 10:25:34 +03:00
1ad79c8187 MDEV-19679 - CREATE SERVER needs tweaks for compatibility with CONNECT engine 2019-09-20 01:54:38 -07:00
95cdc1ca5f Merge commit '43882e764d6867c6855b1ff057758a3f08b25c55' into 10.4 2019-08-13 11:42:31 +04:00
c6efbc543d MDEV-17544 No warning when trying to name a primary key constraint.
Warning added.
2019-07-30 21:57:48 +04:00
c07325f932 Merge branch '10.3' into 10.4 2019-05-19 20:55:37 +02:00
be85d3e61b Merge 10.2 into 10.3 2019-05-14 17:18:46 +03:00
26a14ee130 Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
cb248f8806 Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
5543b75550 Update FSF Address
* Update wrong zip-code
2019-05-11 21:29:06 +03:00
4abb8216a0 MDEV-17658 change the structure of mysql.user table
Implement User_table_json.
Fix scripts to use mysql.global_priv.
Fix tests.
2018-12-12 00:31:44 +01:00
4447a02cf1 MDEV-16991 Rounding vs truncation for TIME, DATETIME, TIMESTAMP 2018-11-26 08:10:47 +04:00
ead9a34a3e MDEV-15851 Stop creating mysql.host table
Changed bootstrap scripts, adjusted result files.
2018-08-16 18:12:13 +01:00
734db318ac Merge 10.3 into 10.4 2018-08-16 10:08:30 +03:00
d6d63f4844 MDEV-16421 Make system tables crash safe
Make all system tables in mysql directory of type
engine=Aria

Privilege tables are using transactional=1
Statistical tables are using transactional=0, to allow them
to be quickly updated with low overhead.
Help tables are also using transactional=0 as these are only
updated at init time.

Other changes:
- Aria store engine is now a required engine
- Update comment for Aria tables to reflect their new usage
- Fixed that _ma_reset_trn_for_table() removes unlocked table
  from transaction table list. This was needed to allow one
  to lock and unlock system tables separately from other
  tables, for example when reading a procedure from mysql.proc
- Don't give a warning when using transactional=1 for engines
  that is using transactions. This is both logical and also
  to avoid warnings/errors when doing an alter of a privilege
  table to InnoDB.
- Don't abort on warnings from ALTER TABLE for changes that
  would be accepted by CREATE TABLE.
- New created Aria transactional tables are marked as not movable
  (as they include create_rename_lsn).
- bootstrap.test was changed to kill orignal server, as one
  can't anymore have two servers started at same time on same
  data directory and data files.
- Disable maria.small_blocksize as one can't anymore change
  aria block size after system tables are created.
- Speed up creation of help tables by using lock tables.
- wsrep_sst_resync now also copies Aria redo logs.
2018-08-14 12:18:38 +03:00
05459706f2 Merge 10.2 into 10.3 2018-08-03 15:57:23 +03:00
de469a2f29 MDEV-14637: Fix hang due to persistent statistics
Similar to the tables SYS_FOREIGN and SYS_FOREIGN_COLS,
the tables mysql.innodb_table_stats and mysql.innodb_index_stats
are updated by the InnoDB internal SQL parser, which fails to
enforce the size limits of the data. Due to this, it is possible
for InnoDB to hang when there are persistent statistics defined on
partitioned tables where the total length of table name,
partition name and subpartition name exceeds the incorrectly
defined limit VARCHAR(64). That column should have been defined
as VARCHAR(199).

btr_node_ptr_max_size(): Interpret the VARCHAR(64) as VARCHAR(199),
to prevent a hang in the case that the upgrade script has not been
run.

dict_table_schema_check(): Ignore difference in the length of the
table_name column.

ha_innobase::max_supported_key_length(): For innodb_page_size=4k,
return a larger value so that the table mysql.innodb_index_stats
can be created. This could allow "impossible" tables to be created,
such that it is not possible to insert anything into a secondary
index when both the secondary key and the primary key are long,
but this is the easiest and most consistent way. The Oracle fix
would only ignore the maximum length violation for the two
statistics tables.

os_file_get_status_posix(), os_file_get_status_win32(): Handle
ENAMETOOLONG as well.

This patch is based on the following change in MySQL 5.7.23.
Not all changes were applied, and our variant allows persistent
statistics to work without hangs even if the table definitions
were not upgraded.

From fdbdce701ab8145ae234c9d401109dff4e4106cb Mon Sep 17 00:00:00 2001
From: Aditya A <aditya.a@oracle.com>
Date: Thu, 17 May 2018 16:11:43 +0530
Subject: [PATCH] Bug #26390736 THE FIELD TABLE_NAME (VARCHAR(64)) FROM
           MYSQL.INNODB_TABLE_STATS CAN OVERFLOW.

    In mysql.innodb_index_stats and mysql.innodb_table_stats
    tables the table name column didn't take into consideration
    partition names which can be more than varchar(64).
2018-08-03 08:33:38 +03:00
583eb96c24 MDEV-11952 Oracle-style packages: stage#5
- CREATE PACKAGE [BODY] statements are now
  entirely written to mysql.proc with type='PACKAGE' and type='PACKAGE BODY'.
- CREATE PACKAGE BODY now supports IF NOT EXISTS
- DROP PACKAGE BODY now supports IF EXISTS
- CREATE OR REPLACE PACKAGE [BODY] is now supported
- CREATE PACKAGE [BODY] now support the DEFINER clause:

    CREATE DEFINER user@host PACKAGE pkg ... END;
    CREATE DEFINER user@host PACKAGE BODY pkg ... END;

- CREATE PACKAGE [BODY] now supports SQL SECURITY and COMMENT clauses, e.g.:

    CREATE PACKAGE p1 SQL SECURITY INVOKER COMMENT "comment" AS ... END;

- Package routines are now created from the package CREATE PACKAGE BODY
  statement and don't produce individual records in mysql.proc.

- CREATE PACKAGE BODY now supports package-wide variables.
  Package variables can be read and set inside package routines.
  Package variables are stored in a separate sp_rcontext,
  which is cached in THD on the first packate routine call.

- CREATE PACKAGE BODY now supports the initialization section.

- All public routines (i.e. declared in CREATE PACKAGE)
  must have implementations in CREATE PACKAGE BODY

- Only public package routines are available outside of the package

- {CREATE|DROP} PACKAGE [BODY] now respects CREATE ROUTINE and ALTER ROUTINE
  privileges

- "GRANT EXECUTE ON PACKAGE BODY pkg" is now supported

- SHOW CREATE PACKAGE [BODY] is now supported

- SHOW PACKAGE [BODY] STATUS is now supported

- CREATE and DROP for PACKAGE [BODY] now works for non-current databases

- mysqldump now supports packages

- "SHOW {PROCEDURE|FUNCTION) CODE pkg.routine" now works for package routines

- "SHOW PACKAGE BODY CODE pkg" now works (the package initialization section)

- A new package body level MDL was added

- Recursive calls for package procedures are now possible

- Routine forward declarations in CREATE PACKATE BODY are now supported.

- Package body variables now work as SP OUT parameters

- Package body variables now work as SELECT INTO targets

- Package body variables now support ROW, %ROWTYPE, %TYPE
2018-02-25 21:08:19 +04:00
f7621f17bd rename mysql.user and mysql.db column
Truncate_versioning_priv->Delete_history_priv

because the command and the privilege were renamed
2018-02-12 23:43:48 +01:00
d943d7f712 MDEV-13417 UPDATE produces wrong values if an updated column is later used as an update source
Standard compatible behavior for UPDATE: all assignments in SET
are executed "simultaneously", not left-to-right. And `SET a=b,b=a`
will swap the values.
2018-02-12 13:14:23 +01:00
d5e37621cf Scripts: VTMD_TEMPLATE removed [#286] 2017-12-17 12:32:33 +03:00
f149013393 rename versioning_* variables 2017-12-14 11:31:44 +01:00
79dd77e6ae System Versioning 1.0 pre3
Merge branch '10.3' into trunk
2017-12-11 15:43:41 +03:00
f4270fc544 s/Delete_versioning_rows_priv/Truncate_versioning_priv/
because the statement is TRUNCATE, not DELETE
2017-12-08 16:26:16 +03:00
60c446584c MDEV-7773: Aggregate stored functions
This commit implements aggregate stored functions. The basic idea behind
the feature is:

* Implement a special instruction FETCH GROUP NEXT ROW that will pause
the execution of the stored function. When the instruction is reached,
execution of the initial query resumes "as if" the function returned.
This gives the server the opportunity to advance to the next row in the
result set.

* Stored aggregates behave like regular aggregate functions. The
implementation of thus resides in the class Item_sum_sp. Because it is
an aggregate function, for each new row in the group, the
Item_sum_sp::add() method will be called. This is when execution resumes
and the function does another iteration to "add" one extra element to
the final result.

* When the end of group is reached, val_xxx() method will be called for
the item. This case is handled by another execute step for the stored
function, only with a special flag to force a call to the return
handler. See Item_sum_sp::execute() for details.

To allow this pause and resume semantic, we must preserve the function
context across executions. This is stored in Item_sp::sp_query_arena only for
aggregate stored functions, but has no impact for regular functions.

We also enforce aggregate functions to include the "FETCH GROUP NEXT ROW"
instruction.

Signed-off-by: Vicențiu Ciorbaru <vicentiu@mariadb.org>
2017-12-04 13:22:29 +02:00
33085349e9 IB, SQL: removed VTQ, added TRT on SQL layer [closes #305] 2017-11-15 00:22:10 +03:00
a80c71dfbb Scripts: bootstrap fix [#307] 2017-11-13 19:11:04 +03:00
d8d7251019 System Versioning pre0.12
Merge remote-tracking branch 'origin/archive/2017-10-17' into 10.3
2017-11-07 00:37:49 +03:00
835cbbcc7b Merge remote-tracking branch 'origin/bb-10.2-ext' into 10.3
TODO: enable MDEV-13049 optimization for 10.3
2017-10-30 20:47:39 +04:00
75aabd03d5 MDEV-14013 : sql_mode=EMPTY_STRING_IS_NULL 2017-10-14 17:28:54 +04:00
a49239b57a SQL: truncate syntax and privilege [closes #229] 2017-09-08 10:22:24 +03:00
c2a70c8050 SQL, IB: option to drop historical rows on ALTER [closes #249] 2017-09-01 12:41:46 +03:00
448374a228 SQL, IB: (0.10) VTMD tracking [closes #124]
IB: Fixes in logic when to do versioned or usual row updates. Now it is
able to do unversioned updates for versioned tables just by disabling
`TABLE_SHARE::versioned` flag.

SQL: DDL tracking for:
* RENAME TABLE, ALTER TABLE .. RENAME TO;
* DROP TABLE;
* data-modifying operations (f.ex. ALTER TABLE .. ADD/DROP COLUMN).
2017-06-19 15:21:39 +03:00
1c8a2de73e Scripts: VTMD schema fix 2017-05-25 15:26:05 +03:00
45f6acd296 Scripts: VTMD table [closes #122] 2017-05-24 18:46:56 +03:00
fdf2d40770 MDEV-12179: Per-engine mysql.gtid_slave_pos table
Intermediate commit.

Implement auto-creation of mysql.gtid_slave_pos* tables with needed engines,
if listed in --gtid-pos-auto-engines.

Uses an asynchronous approach to minimise locking overhead.

The list of available tables is extended with a flag. Extra entries are
added for --gtid-pos-auto-engines tables that do not exist yet, marked as
not existing but ready for auto-creation.

If record_gtid() needs a table marked for auto-creation, it sends a request
to the slave background thread to create the table, and continues to use an
existing table for the current and immediately coming transactions.

As soon as the slave background thread has made the new table available, it
will be used for all subsequent relevant transactions in record_gtid().

This asynchronous approach also avoids a lot of complex issues around trying
to do DDL in the middle of an on-going transaction.
2017-04-21 10:30:16 +02:00
932646b1ff Merge branch '10.1' into 10.2 2016-06-30 16:38:05 +02:00
87e3e67f43 Merge branch '10.0' into 10.1 2016-05-04 15:23:26 +02:00
c788a13c64 Drop old not used mysql.ndb_binlog_index if exists 2016-05-01 19:10:51 +03:00