Bug#24761774	PACKAGE UPGRADE FROM 5.6.33 TO 34 FAILING DUE TO SECURE-…

…FILE-PRIV PROBLEMS

Added creation of missing directory to server postinst

(cherry picked from commit e23c9bd1a18e4914b0371be049a2af8ee01e6e02)

Merge branch 'mysql-5.6' into mysql-5.7

(cherry picked from commit 710bafee9de1c11577242d694f74f5fa38df3a88)

Bug #24740291: YASSL UPDATE TO 2.4.2

Merge branch 'mysql-5.5' into mysql-5.6

(cherry picked from commit fa1aafe9819cb2d9389968f95f91f00f58997df4)

Bug#24464380 PRIVILEGE ESCALATION USING MYSQLD_SAFE

Post push fix: Solaris 10 /bin/sh don't understand $().

WL#6392 : Upgrade to Transactional Data Dictionary

With the implementation of the new data dictionary, the metadata will
be stored in the InnoDB tables. For the users to upgrade from the older
MySQL version(5.7) to mysql-8.0, dictionary tables should be created and
populated in old data directory from various metadata sources.

When the Mysql-8.0 server comes up, it detects for the presence of
dictionary tables.  If dictionary tables are not present,
they will be created in old data directory and populated
with the metadata. Then the server will proceed with normal start.

If dictionary tables are present, server will proceed with normal startup.

Upgrade Steps for Users
------------------------

1. Do a pre requisite check on 5.7 data directory.
2. Do a slow shutdown of mysql-5.7 server. Slow shutdown involves setting
   global variable 'innodb_fast_shutdown' to zero before server shutdown.
3. Start mysql-8.0 server on 5.7 data directory.
   mysql-8.0 server will detect if Dictionary tables are present or not.
   If dictionary tables are not present,  they will be created in old data
   directory. Metadata will be populated in dictionary tables.
   Then server will proceed with normal start.
4. Execute mysql_upgrade client tool.
5. Shutdown and start server again with normal configuration. (Recommended)

Reviewed-by: Nisha Gopalakrishnan <[email protected]>
Reviewed-by: Thayumanavar Sachithanantham <[email protected]>
Reviewed-by: Dmitry Lenev <[email protected]>

Bug#24482156 EXTEND WL#7150: REMOVE USE OF DATADIR IN MYSQLD_SAFE TO …

…SCRIPTS

Don't read config file in datadir in SysV initscript.

(cherry picked from commit 20f91166e073e4279ce14a608fc062f1c9ea5a5f)

Bug#23604483 GCOLS: MINIMAL BINLOG_ROW_IMAGE LEAD TO CORRUPTION/CRASH…

… ON SLAVE

========
Problem:
========
Slave crashes when it is trying to apply an UPDATE row event
(with virtual generated columns) that came from a Master with
BINLOG_ROW_IMAGE=MINIMAL setting.

=========
Analysis:
=========

=============================================================
read_set/write_set bits requirement for GCol computation:
=============================================================
Stored generated columns are computed during an operation and
the value is stored inside storage engine. The computed value will be used
incase of next operation on that column. But Virtual generated column
values, unlike storged generated columns, computed always on the fly and
will not be stored anywhere. But if there is an index on top of virtual
generated columns, it will be maintained by Storage engine. The code
that is required to compute the Virtual generated columns on the fly
is added to all the handler functions (ha_rnd_pos, ha_rnd_next,
ha_index_read_map and etc.,). But due to performance reasons,
it will be computed only when the caller explictly asked to do so by
setting it's flag in read_set bitmap.
mark_generated_columns() function is used to set read_set/write_set
flags that are required to do generated columns modifications
(insert/update/delete).

=========================================================================
'Innodb' Storage engine behaviour/expecation in case of DMLs (update operations)
=========================================================================
In case DMLs are the ongoing operations and exclusive lock is acquired on
the table (which is true for all DMLs), fetch_all_key is set to true i.e.,
storage engine ignores table->read_set and fetches all the column values.
If a primary key (or the keys that can retrieve the tuple uniquely) is provided
to storage engine, storage engine will retrieve all column values from the clustered index
and fills the tuple struture (struct record) with all the column values
irrespective of what is there in table->read_set bitmap.

Also, Storage engine expects all the column values are ready in before_image
before calling ha_update_row, so that the value of a column from the image
can be used as key to find second index entry in case the index entry needs
to be updated.

=============================================================
RBR behaviour when BINLOG_ROW_IMAGE=MINIMAL and setting of
read_set/write_set bits in that setting:
=============================================================
In MySQL row-based replication, each row change event contains two images, a
“before” image whose columns are matched against when searching for the row
to be updated, and an “after” image containing the changes.
In case of MINIMAL setting, for the before image, it is necessary only that
the minimum set of columns required to uniquely identify rows is logged.
If the table containing the row has a primary key, then only the primary key
column or columns are written to the binary log. In the replication flow,
read_set and write_set bitmaps are also used to decide what all the columns
needs to be packed to write into the binary log.

=============================
Analysis on the server crash
=============================
Only DDLs and DMLs are replicated (SELECTs are never replicated).
With the above explanation, storage engines always return all the column
values in case of DMLs (i.e., fetch_all_key is true always for DMLs).
So in pure replication flow (i.e., RBR on slave does not go through regular
optimzer layer) never sets read_set bits to decide what needs to be retrieved
from the storage engine as it was getting all the column values from the
storage engine irrespective of what is there in 'read_set' bitmap.
But since virtual generated columns are not maintained by storage engine
and the retriveal/computation of virtual generated columns are depends on
its bit value in read_set bitmap, it is not computed now. Hence it is not
filled in before_image struture when RBR logic called handler function(in this
example, ha_rnd_pos).
Later when RBR called ha_update_row and storage engine wanted to update secondary
index created on virtua column(which is maintained by storage engine), it tries
to find secondary index entry for the given virtual column value (which is
NULL) and crashes there.

====
Fix:
====
Call mark_generated_columns() before calling any handler functions to
retrieve the before_image. This function will make sure to set all
the read_set/write_set bits that are required to compute/update
virutal columns.

binlog_prepare_row_image() function, which will be called from
binlogging functions (binlog_update_row() and binlog_delete_row())
will take care of removing these spurious fields required during execution
but not needed for binlogging. In case of inserts, there are no spurious
fields (all the columns are required to be written into the binlog)

Along with the fix, the patch is removing some code that was added
for testing purpose (in all three paths, INDEX_SCAN, TABLE_SCAN and
HASH_SCAN).

-  // Temporary fix to find out why it fails [/Matz]
-  memcpy(m_table->read_set->bitmap, m_cols.bitmap, (m_table->read_set->n_bits + 7) / 8);

(cherry picked from commit f8f0611a25df6ae1122fc3b27485d5d14d535e81)

Followup: BUG#23479595 SEGMENTATION FAULT WHEN SELECT FTS INDEX

          TABLES IN INFORMATION SCHEMA

BUG#23742339 FAILING ASSERTION: SYM_NODE->TABLE != NULL

Problem: When we access fts aux tables in information schema,the
fts aux tables are dropped by DROP DATABASE in another session.

Solution: Block DDL by s-locking dict_operation_lock.

Reviewed-by: Jimmy Yang <[email protected]>
RB: 13264
(cherry picked from commit c45124a0b582d57ac6cf20b786e0c643ec9ce941)

Bug#23736787 - YUM UPDATE FAIL FROM 5.5.51(COMUNITY/COMMERCIAL) TO 5.…

…6.32(COMUNITY/COMMERCIAL)

Remove mysql_config from client sub-package

(cherry picked from commit 45c4bfa0f3f1c70756591f48710bb3e76ffde9bc)