Commit graph

1803 commits

Author SHA1 Message Date
Oleksandr Byelkin
51f9d62005 Merge branch '10.11' into 11.0 2023-08-09 07:53:48 +02:00
Oleksandr Byelkin
036df5f970 Merge branch '10.10' into 10.11 2023-08-08 14:57:31 +02:00
Oleksandr Byelkin
ced243a099 Merge branch '10.9' into 10.10 2023-08-05 20:34:09 +02:00
Oleksandr Byelkin
34a8e78581 Merge branch '10.6' into 10.9 2023-08-04 08:01:06 +02:00
Sergei Golubchik
1ba5a0205c MDEV-31836 mysqldump against MYSQL server 8 creates invalid dump
`select * from information_schema.columns` can return columns in any
order, but we need them ordered by the ordinal position
2023-08-03 14:24:16 +02:00
Oleksandr Byelkin
6bf8483cac Merge branch '10.5' into 10.6 2023-08-01 15:08:52 +02:00
Oleksandr Byelkin
65405308a1 Merge branch '10.4' into 10.5 2023-08-01 11:52:13 +02:00
Sergei Golubchik
ab10a675ac MDEV-31092 mysqldump --force doesn't ignore error as it should
failed SHOW CREATE FUNCTION means we don't dump this function,
but should still try to dump all other functions
2023-07-31 22:46:47 +02:00
Oleksandr Byelkin
f52954ef42 Merge commit '10.4' into 10.5 2023-07-20 11:54:52 +02:00
Marko Mäkelä
a906046f1f Merge 10.11 into 11.0 2023-07-04 08:20:20 +03:00
Marko Mäkelä
3430767e00 Merge 10.10 into 10.11 2023-07-04 08:19:48 +03:00
Marko Mäkelä
c2d5523545 Merge 10.9 into 10.10 2023-07-04 08:18:30 +03:00
Oleg Smirnov
6d911219d6 MDEV-30639 Upgrade to 10.8 and later does not work on Windows
During the upgrade procedure on Windows mysqld.exe is started with
the named pipe connection protocol. mysqladmin.exe then pings the
server to check if is up and running. Command line looks like:
   mysqladmin.exe --protocol=pipe --socket=mysql_upgrade_service_xxx ping
But the "socket" parameter resets the "protocol" which was previously
initialized with the "pipe" value, setting it to "socket".
As a result, connection cannot be established and the upgrade
procedure fails.
"socket" in Windows is used to pass the name of the pipe so resetting
the protocol is not valid in this case.

This commit fixes resetting of the "protocol" parameter with "socket"
parameter in the case when protocol has been previously initialized
to "pipe" value
2023-06-30 15:59:14 +07:00
Oleg Smirnov
8e2b20bfb0 MDEV-30639 Upgrade to 10.8 and later does not work on Windows
During the upgrade procedure on Windows mysqld.exe is started with
the named pipe connection protocol. mysqladmin.exe then pings the
server to check if is up and running. Command line looks like:
   mysqladmin.exe --protocol=pipe --socket=mysql_upgrade_service_xxx ping
But the "socket" parameter resets the "protocol" which was previously
initialized with the "pipe" value, setting it to "socket".
As a result, connection cannot be established and the upgrade
procedure fails.
"socket" in Windows is used to pass the name of the pipe so resetting
the protocol is not valid in this case.

This commit fixes resetting of the "protocol" parameter with "socket"
parameter in the case when protocol has been previously initialized
to "pipe" value
2023-06-29 19:16:45 +07:00
Sergei Golubchik
d32fc5b8e0 MDEV-31461 mariadb SIGSEGV when built with -DCLIENT_PLUGIN_DIALOG=STATIC 2023-06-19 12:12:21 +02:00
Sergei Golubchik
0005f2f06c Merge branch 'bb-10.11-release' into bb-11.0-release 2023-06-05 19:27:00 +02:00
Oleksandr Byelkin
06d03dcdd3 Merge branch '10.10' into 10.11 2023-05-03 21:05:34 +02:00
Marko Mäkelä
e02a2f4e9f Merge 10.9 into 10.10 2023-05-02 10:22:43 +03:00
Marko Mäkelä
d8997f875e Merge 10.8 into 10.9 2023-04-28 13:39:33 +03:00
Marko Mäkelä
5028b7c7c8 Merge 10.6 into 10.8 2023-04-27 17:14:36 +03:00
Monty
f272463b02 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.
2023-04-27 11:34:26 +03:00
Sergei Petrunia
c7fe8e51de Merge 10.11 into 11.0 2023-04-17 16:50:01 +03:00
Marko Mäkelä
656c2e18b1 Merge 10.10 into 10.11 2023-04-14 13:08:28 +03:00
Marko Mäkelä
a009280e60 Merge 10.9 into 10.10 2023-04-14 12:24:14 +03:00
Marko Mäkelä
44281b88f3 Merge 10.8 into 10.9 2023-04-14 11:32:36 +03:00
Marko Mäkelä
1d1e0ab2cc Merge 10.6 into 10.8 2023-04-12 15:50:08 +03:00
Marko Mäkelä
5bada1246d Merge 10.5 into 10.6 2023-04-11 16:15:19 +03:00
Oleksandr Byelkin
ac5a534a4c Merge remote-tracking branch '10.4' into 10.5 2023-03-31 21:32:41 +02:00
Anel Husakovic
023bb2fc20 MDBF-534: Coverity scan: fix client folder
--------------------------------
    File: `mysqldump`:
    --------------------------------
    -Coverity (`BAD_SHIFT`):
    https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53073433&mergedDefectId=1211186&eventId=53073433-25

    `mysqldump` - Error obtained by coverity is implication of type
    conversion.
    It may happen that function `find_type` returns -1 which
    is assigned to `uint` that gets converted by compiler to max
    (UINT_32/64). In that situation left bit shift may lead to UB.
    Converting from `uint` to `int` will solve the problem.

    - Coverity (`RESOURCE_LEAK`):
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53072912&mergedDefectId=1519239
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53073706&mergedDefectId=1519368
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53073560&mergedDefectId=1519655
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53074494&mergedDefectId=1519822&fileStart=4001&fileEnd=4250
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53074999&mergedDefectId=1519915&eventId=53074999-53
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53075060&mergedDefectId=1519964
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53073268&mergedDefectId=1519967
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53073015&mergedDefectId=1520164

    `mysqldump` - in case of error memory should be freeed.

    - Coverity (`UNINT`) - FALSE POSITIVES:
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53074364&mergedDefectId=1519587&eventId=53074364-10
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53072619&mergedDefectId=1519684&eventId=53072619-1
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53073256&mergedDefectId=1519722
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53074251&mergedDefectId=1519979
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53074996&mergedDefectId=1520021
      - https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728415&defectInstanceId=53073425&mergedDefectId=1520166&eventId=53073425-9

    ---------------------------------
    File: `mysqladmin`
    ---------------------------------
    - Coverity (PRECEDANCE_ERROR) a.k.a MDEV-15736:
      https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728425&defectInstanceId=53074187&mergedDefectId=1519944

    - Coverity (BAD_FREE) - FALSE POSITIVE:
      https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728425&defectInstanceId=53074614&mergedDefectId=1520042

    ---------------------------------
    File: `mysqlimport`
    ---------------------------------
    - FALSE POSITIVES
      - Coverity (TAINTED_SCALAR):
        https://scan5.scan.coverity.com/reports.htm#v58936/p10357/  fileInstanceId=231728411&defectInstanceId=53074012&mergedDefectId=1519158&eventId=53074012-6
      - Coverity (UNINT):
        https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728411&defectInstanceId=53072860&mergedDefectId=1520020

    ---------------------------------
    File: `mysqlshow`
    ---------------------------------
    - FALSE POSITIVES
      - Coverity (TAINTED_SCALAR):
        https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728418&defectInstanceId=53074361&mergedDefectId=1519232&eventId=53074361-4
      - Coverity (UNINT):
        https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728411&defectInstanceId=53072860&mergedDefectId=1520020

      - Coverity (BAD_FREE):
        https://scan5.scan.coverity.com/reports.htm#v58936/p10357/fileInstanceId=231728418&defectInstanceId=53073408&mergedDefectId=1519972
2023-02-17 13:43:43 +00:00
Marko Mäkelä
2e431ff7e6 Merge 10.11 into 11.0 2023-02-16 13:34:45 +02:00
Oleksandr Byelkin
c7c415734d Merge branch '10.10' into 10.11 2023-01-31 11:07:08 +01:00
Oleksandr Byelkin
76bcea3154 Merge branch '10.9' into 10.10 2023-01-31 11:01:48 +01:00
Oleksandr Byelkin
de2d089942 Merge branch '10.8' into 10.9 2023-01-31 10:37:31 +01:00
Oleksandr Byelkin
b923b80cfd Merge branch '10.6' into 10.7 2023-01-31 09:33:58 +01:00
Oleksandr Byelkin
c3a5cf2b5b Merge branch '10.5' into 10.6 2023-01-31 09:31:42 +01:00
Oleksandr Byelkin
a977054ee0 Merge branch '10.3' into 10.4 2023-01-28 18:22:55 +01:00
Oleksandr Byelkin
7fa02f5c0b Merge branch '10.4' into 10.5 2023-01-27 13:54:14 +01:00
Oleksandr Byelkin
dd24fa3063 Merge branch '10.3' into 10.4 2023-01-26 10:34:26 +01:00
Mikhail Chalov
567b681299 Minimize unsafe C functions usage - replace strcat() and strcpy() (and strncat() and strncpy()) with custom safe_strcat() and safe_strcpy() functions
The MariaDB code base uses strcat() and strcpy() in several
places. These are known to have memory safety issues and their usage is
discouraged. Common security scanners like Flawfinder flags them. In MariaDB we
should start using modern and safer variants on these functions.

This is similar to memory issues fixes in 19af1890b5
and 9de9f105b5 but now replace use of strcat()
and strcpy() with safer options strncat() and strncpy().

However, add '\0' forcefully to make sure the result string is correct since
for these two functions it is not guaranteed what new string will be null-terminated.

Example:

    size_t dest_len = sizeof(g->Message);
    strncpy(g->Message, "Null json tree", dest_len); strncat(g->Message, ":",
    sizeof(g->Message) - strlen(g->Message)); size_t wrote_sz = strlen(g->Message);
    size_t cur_len = wrote_sz >= dest_len ? dest_len - 1 : wrote_sz;
    g->Message[cur_len] = '\0';

All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the BSD-new
license. I am contributing on behalf of my employer Amazon Web Services

-- Reviewer and co-author Vicențiu Ciorbaru <vicentiu@mariadb.org>
-- Reviewer additions:
* The initial function implementation was flawed. Replaced with a simpler
  and also correct version.
* Simplified code by making use of snprintf instead of chaining strcat.
* Simplified code by removing dynamic string construction in the first
  place and using static strings if possible. See connect storage engine
  changes.
2023-01-20 15:18:52 +02:00
Sergei Golubchik
eb26bf6e09 unify client/tool version string
it should now always be

/path/to/exe Ver <tool version> Distrib <server version> for <OS> (<ARCH>)

in all tools and clients
2023-01-19 12:39:28 +01:00
Daniel Black
a5be6c91cb MDEV-29889 mariadb-dump --tab --header is slow
--header applied an ORDER BY to ensure that the header
row was the first row in the output given UNION ALL
doesn't in the standard enforce the order.

We change that now only add the ORDER BY if --order-by-primary
is used.

An assumption that if UNION ALL change to a different behaviour
the resulting mysqldump-header test may also change.
2023-01-03 14:57:02 +11:00
Oleksandr Byelkin
ad937cf33a Merge branch '10.10' into 10.11 2022-11-02 13:08:01 +01:00
Oleksandr Byelkin
49a22c5897 Merge branch '10.9' into 10.10 2022-11-01 11:55:28 +01:00
Oleksandr Byelkin
ebf2121529 Merge branch '10.8' into 10.9 2022-11-01 10:33:44 +01:00
Oleksandr Byelkin
1ebfa2af62 Merge branch '10.6' into 10.7 2022-10-29 19:22:04 +02:00
Sergei Golubchik
dc3be24268 MDEV-29828 Indicate that --dump-history only applies to timestamp-based versioning 2022-10-26 15:30:39 +02:00
Sergei Golubchik
a6f9694650 MDEV-29736 mysqldump sets system_versioning_insert_history=1 twice and doesn't restore previous value 2022-10-26 15:30:39 +02:00
Sergei Golubchik
73b2a326d2 MDEV-29730 mysqldump --dump-history creates broken dump if there are precision-versioned tables 2022-10-26 15:30:39 +02:00
Sergei Golubchik
d249761ae5 MDEV-16029 mysqldump: dump and restore historical data 2022-10-26 15:30:39 +02:00
Sergei Golubchik
a39b4848e4 MDEV-16733 mysqldump --tab and --xml options are conflicting 2022-10-26 15:30:39 +02:00