MDEV-31162 Crash for query using ROWNUM over multi-table view with ORDER BY
This bug could cause a crash of the server when processing a query with
ROWNUM() if it used in its FROM list a reference to a mergeable view
defined as SELECT over more than one table that contained ORDER BY clause.
When a mergeable view with ORDER BY clause and without LIMIT clause is used
in the FROM list of a query that does not have ORDER BY clause the ORDER BY
clause of the view is moved to the query. The code that performed this
transformation forgot to delete the moved ORDER BY list from the view.
If a query contains ROWNUM() and uses a mergeable multi-table view with
ORDER BY then according to the current code of TABLE_LIST::init_derived()
the view has to be forcibly materialized. As the query and the view shared
the same items in its ORDER BY lists they could not be properly resolved
either in the query or in the view. This led to a crash of the server.
This patch has returned back the original signature of LEX::can_not_use_merged()
to comply with 10.4 code of the condition that checks whether a megeable
view has to be forcibly materialized.
Approved by Oleksandr Byelkin <email address hidden>
5f3a4be...
by
Tuukka Pasanen <email address hidden>
MDEV-31045: Update debian/rules to be in sync to MariaDB LTS 10.6
To make sure that PMEM problem does not happen again sync
10.9 and up debian/rules to make sure that they are not making
anymore problems with autobake-debs.sh
MDEV-31143 Crash for query using ROWNUM() over view with ORDER BY
When processing a query over a mergeable view at some conditions checked
at prepare stage it may be decided to materialize the view rather than
to merge it. Before this patch in such case the field 'derived' of the
TABLE_LIST structure created for the view remained set to 0. As a result
the guard condition preventing range analysis for materialized views did
not work properly. This led to a call of some handler method for the
temporary table created to contain the view's records that was supposed
to be used only for opened tables. However temporary tables created for
materialization of derived tables or views are not opened yet when range
analysis is performed.
Approved by Oleksandr Byelkin <email address hidden>
MDEV-31073 Server crash, assertion `table != 0 && view->field_translation != 0' failure with ROWNUM and view
Now the same rule applied to vews and derived tables. So we should
allow merge of views (and derived) in queries with rownum, because
it do not change results, only makes query plans better.
MDEV-29401 InnoDB history list length increased in 10.6 compared to 10.5
The InnoDB buffer pool and locking were heavily refactored in
MariaDB Server 10.6. Among other things, dict_sys.mutex was removed,
and the contended lock_sys.mutex was replaced with a combination of
lock_sys.latch and distributed latches in hash tables. Also, a
default value was changed to innodb_flush_method=O_DIRECT to improve
performance in write-heavy workloads.
One thing where an adjustment was missing is around the parameters
innodb_max_purge_lag (number of committed transactions waiting to
be purged), and innodb_max_purge_lag_delay
(maximum number of microseconds to delay a DML operation).
purge_coordinator_state::do_purge(): Pass the history_size to trx_purge()
and reset srv_dml_needed_delay if the history is empty.
Keep executing the loop non-stop as long as srv_dml_needed_delay is set.
trx_purge_dml_delay(): Made part of trx_purge().
Set srv_dml_needed_delay=0 when nothing can be purged (!n_pages_handled).
row_mysql_delay_if_needed(): Mimic the logic of
innodb_max_purge_lag_wait_update().
Cleanup of MDEV-14974: --port ignored for --host=localhost
The old code added to 10.6 was inconsisting in how TCP/IP and
socket connection was chosen. One got also a confusing warning
in some cases.
Examples:
> ../client/mysql --print-defaults
../client/mysql would have been started with the following arguments:
--socket=/tmp/mariadbd.sock --port=3307 --no-auto-rehash
> ../client/mysql
ERROR 2002 (HY000): Can't connect to local server through socket '/tmp/mariadbd.sock' (2)
> ../client/mysql --print-defaults
../client/mysql would have been started with the following arguments:
--socket=/tmp/mariadbd.sock --port=3307 --no-auto-rehash
> ../client/mysql --port=3333
WARNING: Forcing protocol to TCP due to option specification. Please explicitly state intended protocol.
ERROR 2002 (HY000): Can't connect to server on 'localhost' (111)
> ../client/mysql --port=3333 --socket=sss
ERROR 2002 (HY000): Can't connect to local server through socket 'sss' (2)
> ../client/mysql --socket=sss --port=3333
ERROR 2002 (HY000): Can't connect to local server through socket 'sss' (2)
Some notable things:
- One gets a warning if one uses just --port if config file sets socket
- Using port and socket gives no warning
- Using socket and then port still uses socket
This patch changes things the following ways:
If --port= is given on the command line, the the protocol is automatically
changed to "TCP/IP".
- If --socket= is given on the command line, the protocol is automatically
changed to "socket".
- The last option wins
- No warning is given if protocol changes automatically.
