MariaDB-server/mysql-test/include/grep.inc

# Grep file for regular expression and output to STDOUT
#
# Usage:
# --let $grep_file= /path/to/your/file
# --let $grep_regex= your_regex_string
# --let $grep_filter= filter
# --source include/grep.inc


--perl
  open (my $fh, "<", "$ENV{grep_file}") or die $!;
  while (<$fh>)
  {
    if  (/$ENV{grep_regex}/)
    {
      if ($ENV{grep_filter})
      {
        eval($ENV{grep_filter});
      }
      print;
    }
  }
  close $fh;
EOF
MDEV-28254 Wrong position for row_start, row_end after adding column to implicit versioned table Implicit system-versioned table does not contain system fields in SHOW CREATE. Therefore after mysqldump recovery such table has system fields in the last place in frm image. The original table meanwhile does not guarantee these system fields on last place because adding new fields via ALTER TABLE places them last. Thus the order of fields may be different between master and slave, so row-based replication may fail. To fix this on ALTER TABLE we now place system-invisible fields always last in frm image. If the table was created via old revision and has an incorrect order of fields it can be fixed via any copy operation of ALTER TABLE, f.ex.: ALTER TABLE t1 FORCE; To check the order of fields in frm file one can use hexdump: hexdump -C t1.frm Note, the replication fails only when all 3 conditions are met: 1. row-based or mixed mode replication; 2. table has new fields added via ALTER TABLE; 3. table was rebuilt on some, but not all nodes via mysqldump image. Otherwise it will operate properly even with incorrect order of fields. 2022-04-22 15:49:37 +03:00			`# Grep file for regular expression and output to STDOUT`
			`#`
			`# Usage:`
			`# --let $grep_file= /path/to/your/file`
			`# --let $grep_regex= your_regex_string`
MDEV-32188 make TIMESTAMP use whole 32-bit unsigned range This patch extends the timestamp from 2038-01-19 03:14:07.999999 to 2106-02-07 06:28:15.999999 for 64 bit hardware and OS where 'long' is 64 bits. This is true for 64 bit Linux but not for Windows. This is done by treating the 32 bit stored int as unsigned instead of signed. This is safe as MariaDB has never accepted dates before the epoch (1970). The benefit of this approach that for normal timestamp the storage is compatible with earlier version. However for tables using system versioning we before stored a timestamp with the year 2038 as the 'max timestamp', which is used to detect current values. This patch stores the new 2106 year max value as the max timestamp. This means that old tables using system versioning needs to be updated with mariadb-upgrade when moving them to 11.4. That will be done in a separate commit. 2023-09-11 17:58:22 +03:00			`# --let $grep_filter= filter`
MDEV-28254 Wrong position for row_start, row_end after adding column to implicit versioned table Implicit system-versioned table does not contain system fields in SHOW CREATE. Therefore after mysqldump recovery such table has system fields in the last place in frm image. The original table meanwhile does not guarantee these system fields on last place because adding new fields via ALTER TABLE places them last. Thus the order of fields may be different between master and slave, so row-based replication may fail. To fix this on ALTER TABLE we now place system-invisible fields always last in frm image. If the table was created via old revision and has an incorrect order of fields it can be fixed via any copy operation of ALTER TABLE, f.ex.: ALTER TABLE t1 FORCE; To check the order of fields in frm file one can use hexdump: hexdump -C t1.frm Note, the replication fails only when all 3 conditions are met: 1. row-based or mixed mode replication; 2. table has new fields added via ALTER TABLE; 3. table was rebuilt on some, but not all nodes via mysqldump image. Otherwise it will operate properly even with incorrect order of fields. 2022-04-22 15:49:37 +03:00			`# --source include/grep.inc`

MDEV-32188 make TIMESTAMP use whole 32-bit unsigned range This patch extends the timestamp from 2038-01-19 03:14:07.999999 to 2106-02-07 06:28:15.999999 for 64 bit hardware and OS where 'long' is 64 bits. This is true for 64 bit Linux but not for Windows. This is done by treating the 32 bit stored int as unsigned instead of signed. This is safe as MariaDB has never accepted dates before the epoch (1970). The benefit of this approach that for normal timestamp the storage is compatible with earlier version. However for tables using system versioning we before stored a timestamp with the year 2038 as the 'max timestamp', which is used to detect current values. This patch stores the new 2106 year max value as the max timestamp. This means that old tables using system versioning needs to be updated with mariadb-upgrade when moving them to 11.4. That will be done in a separate commit. 2023-09-11 17:58:22 +03:00
MDEV-28254 Wrong position for row_start, row_end after adding column to implicit versioned table Implicit system-versioned table does not contain system fields in SHOW CREATE. Therefore after mysqldump recovery such table has system fields in the last place in frm image. The original table meanwhile does not guarantee these system fields on last place because adding new fields via ALTER TABLE places them last. Thus the order of fields may be different between master and slave, so row-based replication may fail. To fix this on ALTER TABLE we now place system-invisible fields always last in frm image. If the table was created via old revision and has an incorrect order of fields it can be fixed via any copy operation of ALTER TABLE, f.ex.: ALTER TABLE t1 FORCE; To check the order of fields in frm file one can use hexdump: hexdump -C t1.frm Note, the replication fails only when all 3 conditions are met: 1. row-based or mixed mode replication; 2. table has new fields added via ALTER TABLE; 3. table was rebuilt on some, but not all nodes via mysqldump image. Otherwise it will operate properly even with incorrect order of fields. 2022-04-22 15:49:37 +03:00			`--perl`
			`open (my $fh, "<", "$ENV{grep_file}") or die $!;`
			`while (<$fh>)`
			`{`
MDEV-32188 make TIMESTAMP use whole 32-bit unsigned range This patch extends the timestamp from 2038-01-19 03:14:07.999999 to 2106-02-07 06:28:15.999999 for 64 bit hardware and OS where 'long' is 64 bits. This is true for 64 bit Linux but not for Windows. This is done by treating the 32 bit stored int as unsigned instead of signed. This is safe as MariaDB has never accepted dates before the epoch (1970). The benefit of this approach that for normal timestamp the storage is compatible with earlier version. However for tables using system versioning we before stored a timestamp with the year 2038 as the 'max timestamp', which is used to detect current values. This patch stores the new 2106 year max value as the max timestamp. This means that old tables using system versioning needs to be updated with mariadb-upgrade when moving them to 11.4. That will be done in a separate commit. 2023-09-11 17:58:22 +03:00			`if (/$ENV{grep_regex}/)`
			`{`
			`if ($ENV{grep_filter})`
			`{`
			`eval($ENV{grep_filter});`
			`}`
MDEV-28254 Wrong position for row_start, row_end after adding column to implicit versioned table Implicit system-versioned table does not contain system fields in SHOW CREATE. Therefore after mysqldump recovery such table has system fields in the last place in frm image. The original table meanwhile does not guarantee these system fields on last place because adding new fields via ALTER TABLE places them last. Thus the order of fields may be different between master and slave, so row-based replication may fail. To fix this on ALTER TABLE we now place system-invisible fields always last in frm image. If the table was created via old revision and has an incorrect order of fields it can be fixed via any copy operation of ALTER TABLE, f.ex.: ALTER TABLE t1 FORCE; To check the order of fields in frm file one can use hexdump: hexdump -C t1.frm Note, the replication fails only when all 3 conditions are met: 1. row-based or mixed mode replication; 2. table has new fields added via ALTER TABLE; 3. table was rebuilt on some, but not all nodes via mysqldump image. Otherwise it will operate properly even with incorrect order of fields. 2022-04-22 15:49:37 +03:00			`print;`
MDEV-32188 make TIMESTAMP use whole 32-bit unsigned range This patch extends the timestamp from 2038-01-19 03:14:07.999999 to 2106-02-07 06:28:15.999999 for 64 bit hardware and OS where 'long' is 64 bits. This is true for 64 bit Linux but not for Windows. This is done by treating the 32 bit stored int as unsigned instead of signed. This is safe as MariaDB has never accepted dates before the epoch (1970). The benefit of this approach that for normal timestamp the storage is compatible with earlier version. However for tables using system versioning we before stored a timestamp with the year 2038 as the 'max timestamp', which is used to detect current values. This patch stores the new 2106 year max value as the max timestamp. This means that old tables using system versioning needs to be updated with mariadb-upgrade when moving them to 11.4. That will be done in a separate commit. 2023-09-11 17:58:22 +03:00			`}`
MDEV-28254 Wrong position for row_start, row_end after adding column to implicit versioned table Implicit system-versioned table does not contain system fields in SHOW CREATE. Therefore after mysqldump recovery such table has system fields in the last place in frm image. The original table meanwhile does not guarantee these system fields on last place because adding new fields via ALTER TABLE places them last. Thus the order of fields may be different between master and slave, so row-based replication may fail. To fix this on ALTER TABLE we now place system-invisible fields always last in frm image. If the table was created via old revision and has an incorrect order of fields it can be fixed via any copy operation of ALTER TABLE, f.ex.: ALTER TABLE t1 FORCE; To check the order of fields in frm file one can use hexdump: hexdump -C t1.frm Note, the replication fails only when all 3 conditions are met: 1. row-based or mixed mode replication; 2. table has new fields added via ALTER TABLE; 3. table was rebuilt on some, but not all nodes via mysqldump image. Otherwise it will operate properly even with incorrect order of fields. 2022-04-22 15:49:37 +03:00			`}`
			`close $fh;`
			`EOF`