pkgsrc/databases/mysql56-client/options.mk

53 lines
1.5 KiB
Makefile
Raw Normal View History

Changes 5.6.32: Bugs Fixed InnoDB: Full-text search auxiliary tables could be dropped by one session while being access by another. InnoDB: Selecting full-text index information schema tables for a deleted table caused a segmentation fault. InnoDB: Rollback of a full-text index synchronization operation raised an assertion. The rollback operation attempted to acquire a mutex still held by the background synchronization thread. InnoDB: Setting innodb_monitor_enable to all did not enable all counters. Replication: After issuing a PURGE BINARY LOGS statement, if the binary log index file was not available, for example because it had been opened by another application such as MEB, the server could stop unexpectedly. Although this situation was rare, the handling has been made more robust to avoid unexpected halts and more informative errors are provided. Replication: When using row-based replication and InnoDB, replication slaves reverted to using an older locking scheme when a transaction had already acquired an AUTOINC lock related to a LOAD FILE or INSERT ... SELECT type of statement, reducing replication slave performance. The fix ensures that sql_command is set correctly for any of the DML events such as WRITE_ROWS_EVENT, UPDATE_EVENT, and DELETE_EVENT. Replication: A MySQL version 5.5 slave does not have a server_uuid and replication identified servers by their server_id. Starting from MySQL version 5.6, replication masters detected a zombie dump thread based only on a slave's server_uuid value, under the assumption that each slave has a unique UUID. Connecting a MySQL 5.5 slave to a MySQL 5.6 and later master meant that the master was unable to detect zombie dump threads that were created to serve slaves running versions older than MySQL 5.6. The fix ensures that a master now first checks if a slave has a server_uuid set. If it is set, zombie dump thread detection happens based on the slave's UUID. If a slave's server_uuid is not set, zombie dump thread detection happens based on server_id. Replication: With slave_skip_errors enabled there were still special cases when slave errors were not being correctly ignored. For example: When opening and locking a table failed. When field conversions failed on a server running row-based replication. In these cases the error was considered critical and it was not respecting the state of slave_skip_errors. The fix ensures that with slave_skip_errors enabled, all errors reported during applying a transaction are correctly handled. This means that in such a set up, upon receiving an error with the log_warnings option set to greater than 1, if the error can be ignored then the warning is printed into the error log and the server continues as it does in the case of other ignored errors. Replication: When using statement-based or mixed binary logging format with --read-only=ON, it was not possible to modify temporary tables. MySQL Server upgrades performed using RPM packages failed when upgrading from MySQL 5.5 Community to MySQL 5.6 Community or MySQL 5.5 Commercial to MySQL 5.6 Commercial. The code for reading character set information from Performance Schema statement events tables (for example, events_statements_current) did not prevent simultaneous writing to that information. As a result, the SQL query text character set could be invalid, which could result in a server exit. Now an invalid character set causes SQL_TEXT column truncation. A buffer overflow in the regex library was fixed. Certain arguments to NAME_CONST() could cause a server exit. For unit-testing with the MySQL test suite, the make unit-test command is no longer available. The ctest program should be used instead. See Unit Tests Added to Main Test Runs. ST_Distance() could raise an assertion for NULL return values. With the query cache enabled, executing a prepared statement with CURSOR_TYPE_READ_ONLY and then again with CURSOR_TYPE_NO_CURSOR caused the server to return an error. mysql_real_connect() was not thread-safe when invoked with the MYSQL_READ_DEFAULT_FILE or MYSQL_READ_DEFAULT_GROUP option enabled. Installing MySQL from a yum or zypper repository resulted in /var/log/mysqld.log being created with incorrect user and group permissions. If a stored function updated a view for which the view table had a trigger defined that updated another table, it could fail and report an error that an existing table did not exist. If an INSTALL PLUGIN statement contained invalid UTF-8 characters in the shared library name, it caused the server to hang (or to raise an assertion in debug builds). For multibyte character sets, LOAD DATA could fail to allocate space correctly and ignore input rows as a result.
2016-08-04 12:09:08 +02:00
# $NetBSD: options.mk,v 1.12 2016/08/04 10:09:08 adam Exp $
PKG_OPTIONS_VAR= PKG_OPTIONS.mysql5
# ndb-cluster does not configure with cmake
PKG_SUPPORTED_OPTIONS+= dtrace embedded-server ndb-cluster sphinx ssl
PKG_SUPPORTED_OPTIONS+= memcached
PKG_SUGGESTED_OPTIONS+= embedded-server ssl
.include "../../mk/bsd.options.mk"
# Enable OpenSSL support
.if !empty(PKG_OPTIONS:Mssl)
. include "../../security/openssl/buildlink3.mk"
CMAKE_ARGS+= -DWITH_SSL=system
.else
CMAKE_ARGS+= -DWITH_SSL=no
.endif
2014-03-25 14:56:38 +01:00
# Enable DTrace support
.if !empty(PKG_OPTIONS:Mdtrace)
CMAKE_ARGS+= -DENABLE_DTRACE=ON
.else
CMAKE_ARGS+= -DENABLE_DTRACE=OFF
2014-03-25 14:56:38 +01:00
.endif
# Enable InnoDB Memcached support
PLIST_VARS+= memcached
.if !empty(PKG_OPTIONS:Mmemcached)
PLIST.memcached= yes
CMAKE_ARGS+= -DWITH_INNODB_MEMCACHED=ON
CMAKE_ARGS+= -DWITH_BUNDLED_MEMCACHED=ON
.include "../../devel/libevent/buildlink3.mk"
.else
CMAKE_ARGS+= -DWITH_INNODB_MEMCACHED=OFF
.endif
# Enable Sphinx SE support
# http://sphinxsearch.com/docs/current.html#sphinxse-overview
PLIST_VARS+= sphinx
.if !empty(PKG_OPTIONS:Msphinx) || make(distinfo) || make(makesum) || make(mdi)
Changes 5.6.32: Bugs Fixed InnoDB: Full-text search auxiliary tables could be dropped by one session while being access by another. InnoDB: Selecting full-text index information schema tables for a deleted table caused a segmentation fault. InnoDB: Rollback of a full-text index synchronization operation raised an assertion. The rollback operation attempted to acquire a mutex still held by the background synchronization thread. InnoDB: Setting innodb_monitor_enable to all did not enable all counters. Replication: After issuing a PURGE BINARY LOGS statement, if the binary log index file was not available, for example because it had been opened by another application such as MEB, the server could stop unexpectedly. Although this situation was rare, the handling has been made more robust to avoid unexpected halts and more informative errors are provided. Replication: When using row-based replication and InnoDB, replication slaves reverted to using an older locking scheme when a transaction had already acquired an AUTOINC lock related to a LOAD FILE or INSERT ... SELECT type of statement, reducing replication slave performance. The fix ensures that sql_command is set correctly for any of the DML events such as WRITE_ROWS_EVENT, UPDATE_EVENT, and DELETE_EVENT. Replication: A MySQL version 5.5 slave does not have a server_uuid and replication identified servers by their server_id. Starting from MySQL version 5.6, replication masters detected a zombie dump thread based only on a slave's server_uuid value, under the assumption that each slave has a unique UUID. Connecting a MySQL 5.5 slave to a MySQL 5.6 and later master meant that the master was unable to detect zombie dump threads that were created to serve slaves running versions older than MySQL 5.6. The fix ensures that a master now first checks if a slave has a server_uuid set. If it is set, zombie dump thread detection happens based on the slave's UUID. If a slave's server_uuid is not set, zombie dump thread detection happens based on server_id. Replication: With slave_skip_errors enabled there were still special cases when slave errors were not being correctly ignored. For example: When opening and locking a table failed. When field conversions failed on a server running row-based replication. In these cases the error was considered critical and it was not respecting the state of slave_skip_errors. The fix ensures that with slave_skip_errors enabled, all errors reported during applying a transaction are correctly handled. This means that in such a set up, upon receiving an error with the log_warnings option set to greater than 1, if the error can be ignored then the warning is printed into the error log and the server continues as it does in the case of other ignored errors. Replication: When using statement-based or mixed binary logging format with --read-only=ON, it was not possible to modify temporary tables. MySQL Server upgrades performed using RPM packages failed when upgrading from MySQL 5.5 Community to MySQL 5.6 Community or MySQL 5.5 Commercial to MySQL 5.6 Commercial. The code for reading character set information from Performance Schema statement events tables (for example, events_statements_current) did not prevent simultaneous writing to that information. As a result, the SQL query text character set could be invalid, which could result in a server exit. Now an invalid character set causes SQL_TEXT column truncation. A buffer overflow in the regex library was fixed. Certain arguments to NAME_CONST() could cause a server exit. For unit-testing with the MySQL test suite, the make unit-test command is no longer available. The ctest program should be used instead. See Unit Tests Added to Main Test Runs. ST_Distance() could raise an assertion for NULL return values. With the query cache enabled, executing a prepared statement with CURSOR_TYPE_READ_ONLY and then again with CURSOR_TYPE_NO_CURSOR caused the server to return an error. mysql_real_connect() was not thread-safe when invoked with the MYSQL_READ_DEFAULT_FILE or MYSQL_READ_DEFAULT_GROUP option enabled. Installing MySQL from a yum or zypper repository resulted in /var/log/mysqld.log being created with incorrect user and group permissions. If a stored function updated a view for which the view table had a trigger defined that updated another table, it could fail and report an error that an existing table did not exist. If an INSTALL PLUGIN statement contained invalid UTF-8 characters in the shared library name, it caused the server to hang (or to raise an assertion in debug builds). For multibyte character sets, LOAD DATA could fail to allocate space correctly and ignore input rows as a result.
2016-08-04 12:09:08 +02:00
SPHINX_VER= 2.2.11
DISTFILES= ${DEFAULT_DISTFILES} sphinx-${SPHINX_VER}-release${EXTRACT_SUFX}
Changes 5.6.32: Bugs Fixed InnoDB: Full-text search auxiliary tables could be dropped by one session while being access by another. InnoDB: Selecting full-text index information schema tables for a deleted table caused a segmentation fault. InnoDB: Rollback of a full-text index synchronization operation raised an assertion. The rollback operation attempted to acquire a mutex still held by the background synchronization thread. InnoDB: Setting innodb_monitor_enable to all did not enable all counters. Replication: After issuing a PURGE BINARY LOGS statement, if the binary log index file was not available, for example because it had been opened by another application such as MEB, the server could stop unexpectedly. Although this situation was rare, the handling has been made more robust to avoid unexpected halts and more informative errors are provided. Replication: When using row-based replication and InnoDB, replication slaves reverted to using an older locking scheme when a transaction had already acquired an AUTOINC lock related to a LOAD FILE or INSERT ... SELECT type of statement, reducing replication slave performance. The fix ensures that sql_command is set correctly for any of the DML events such as WRITE_ROWS_EVENT, UPDATE_EVENT, and DELETE_EVENT. Replication: A MySQL version 5.5 slave does not have a server_uuid and replication identified servers by their server_id. Starting from MySQL version 5.6, replication masters detected a zombie dump thread based only on a slave's server_uuid value, under the assumption that each slave has a unique UUID. Connecting a MySQL 5.5 slave to a MySQL 5.6 and later master meant that the master was unable to detect zombie dump threads that were created to serve slaves running versions older than MySQL 5.6. The fix ensures that a master now first checks if a slave has a server_uuid set. If it is set, zombie dump thread detection happens based on the slave's UUID. If a slave's server_uuid is not set, zombie dump thread detection happens based on server_id. Replication: With slave_skip_errors enabled there were still special cases when slave errors were not being correctly ignored. For example: When opening and locking a table failed. When field conversions failed on a server running row-based replication. In these cases the error was considered critical and it was not respecting the state of slave_skip_errors. The fix ensures that with slave_skip_errors enabled, all errors reported during applying a transaction are correctly handled. This means that in such a set up, upon receiving an error with the log_warnings option set to greater than 1, if the error can be ignored then the warning is printed into the error log and the server continues as it does in the case of other ignored errors. Replication: When using statement-based or mixed binary logging format with --read-only=ON, it was not possible to modify temporary tables. MySQL Server upgrades performed using RPM packages failed when upgrading from MySQL 5.5 Community to MySQL 5.6 Community or MySQL 5.5 Commercial to MySQL 5.6 Commercial. The code for reading character set information from Performance Schema statement events tables (for example, events_statements_current) did not prevent simultaneous writing to that information. As a result, the SQL query text character set could be invalid, which could result in a server exit. Now an invalid character set causes SQL_TEXT column truncation. A buffer overflow in the regex library was fixed. Certain arguments to NAME_CONST() could cause a server exit. For unit-testing with the MySQL test suite, the make unit-test command is no longer available. The ctest program should be used instead. See Unit Tests Added to Main Test Runs. ST_Distance() could raise an assertion for NULL return values. With the query cache enabled, executing a prepared statement with CURSOR_TYPE_READ_ONLY and then again with CURSOR_TYPE_NO_CURSOR caused the server to return an error. mysql_real_connect() was not thread-safe when invoked with the MYSQL_READ_DEFAULT_FILE or MYSQL_READ_DEFAULT_GROUP option enabled. Installing MySQL from a yum or zypper repository resulted in /var/log/mysqld.log being created with incorrect user and group permissions. If a stored function updated a view for which the view table had a trigger defined that updated another table, it could fail and report an error that an existing table did not exist. If an INSTALL PLUGIN statement contained invalid UTF-8 characters in the shared library name, it caused the server to hang (or to raise an assertion in debug builds). For multibyte character sets, LOAD DATA could fail to allocate space correctly and ignore input rows as a result.
2016-08-04 12:09:08 +02:00
SITES.sphinx-2.2.11-release.tar.gz= http://sphinxsearch.com/files/
Changes 5.6.27: * InnoDB: The new innodb_numa_interleave read-only configuration option allows you to enable the NUMA interleave memory policy for allocation of the InnoDB buffer pool. When innodb_numa_interleave is enabled, the NUMA memory policy is set to MPOL_INTERLEAVE for the mysqld process. After the InnoDB buffer pool is allocated, the NUMA memory policy is set back to MPOL_DEFAULT. This option is only available on NUMA-enabled systems. * yaSSL was upgraded to version 2.3.8. * RPM .spec files were updated so that MySQL Server builds from source RPM packages will include the proper files to take advantage of operating system NUMA capabilities. This introduces a runtime dependency on libnuma.so.1. RPM and yum detect this and refuse to install if that library is not installed. * InnoDB: Reloading a table that was evicted while empty caused an AUTO_INCREMENT value to be reset. * InnoDB: Memory allocation sanity checks were added to the memcached code. * InnoDB: A memcached flush_all command raised an assertion. A function that starts a transaction was called from within assertion code. * InnoDB: A data corruption occurred on ARM64. GCC builtins did not issue the correct fences when setting or unsetting the lock word. * InnoDB: Server shutdown was delayed waiting for the purge thread to exit. To avoid this problem, the number of calls to trx_purge() was reduced, and the trx_purge() batch size was reduced to 20. * InnoDB: In READ COMMITTED mode, a REPLACE operation on a unique secondary index resulted in a constraint violation. * InnoDB: The IBUF_BITMAP_FREE bit indicated that there was more free space in the leaf page than was actually available. * InnoDB: Setting lower_case_table_names=0 on a case-insensitive file system could result in a hang condition when running an INSERT INTO ... SELECT ... FROM tbl_name operation with the wrong tbl_name letter case. An error message is now printed and the server exits when attempting to start the server with --lower_case_table_names=0 on a case-insensitive file system. * InnoDB: The server failed to start with an innodb_force_recovery setting greater than 3. InnoDB was set to read-only mode before redo logs were applied. * InnoDB: The trx_sys_read_pertable_file_format_id() function reported the wrong file format. * Partitioning: CREATE TABLE statements that used an invalid function in a subpartitioning expression did not always fail gracefully as expected. * Partitioning: Error handling for failed partitioning-related ALTER TABLE operations against non-partitioned tables was not performed correctly * Partitioning: ALTER TABLE when executed from a stored procedure did not always work correctly with tables partitioned by RANGE. * Replication: Repeatedly checking for ERR_LOCK_WAIT_TIMEOUT (as done, for example by repeatedly executing SHOW SLAVE STATUS) during a prolonged write lock on a table led to an assert. * Replication: If statement based logging was in use, when updating multiple tables in a single statement, a single transaction could be logged as two different transactions. This was due to the binary logging process not properly identifying statements which were operating over transactional tables. The fix ensures that they are correctly identified, even if such statements do not change the contents of the tables.
2015-10-03 14:46:13 +02:00
. if !empty(PKGPATH:Mdatabases/mysql56-server)
MESSAGE_SRC= ${PKGDIR}/MESSAGE ${PKGDIR}/MESSAGE.sphinx
Changes 5.6.27: * InnoDB: The new innodb_numa_interleave read-only configuration option allows you to enable the NUMA interleave memory policy for allocation of the InnoDB buffer pool. When innodb_numa_interleave is enabled, the NUMA memory policy is set to MPOL_INTERLEAVE for the mysqld process. After the InnoDB buffer pool is allocated, the NUMA memory policy is set back to MPOL_DEFAULT. This option is only available on NUMA-enabled systems. * yaSSL was upgraded to version 2.3.8. * RPM .spec files were updated so that MySQL Server builds from source RPM packages will include the proper files to take advantage of operating system NUMA capabilities. This introduces a runtime dependency on libnuma.so.1. RPM and yum detect this and refuse to install if that library is not installed. * InnoDB: Reloading a table that was evicted while empty caused an AUTO_INCREMENT value to be reset. * InnoDB: Memory allocation sanity checks were added to the memcached code. * InnoDB: A memcached flush_all command raised an assertion. A function that starts a transaction was called from within assertion code. * InnoDB: A data corruption occurred on ARM64. GCC builtins did not issue the correct fences when setting or unsetting the lock word. * InnoDB: Server shutdown was delayed waiting for the purge thread to exit. To avoid this problem, the number of calls to trx_purge() was reduced, and the trx_purge() batch size was reduced to 20. * InnoDB: In READ COMMITTED mode, a REPLACE operation on a unique secondary index resulted in a constraint violation. * InnoDB: The IBUF_BITMAP_FREE bit indicated that there was more free space in the leaf page than was actually available. * InnoDB: Setting lower_case_table_names=0 on a case-insensitive file system could result in a hang condition when running an INSERT INTO ... SELECT ... FROM tbl_name operation with the wrong tbl_name letter case. An error message is now printed and the server exits when attempting to start the server with --lower_case_table_names=0 on a case-insensitive file system. * InnoDB: The server failed to start with an innodb_force_recovery setting greater than 3. InnoDB was set to read-only mode before redo logs were applied. * InnoDB: The trx_sys_read_pertable_file_format_id() function reported the wrong file format. * Partitioning: CREATE TABLE statements that used an invalid function in a subpartitioning expression did not always fail gracefully as expected. * Partitioning: Error handling for failed partitioning-related ALTER TABLE operations against non-partitioned tables was not performed correctly * Partitioning: ALTER TABLE when executed from a stored procedure did not always work correctly with tables partitioned by RANGE. * Replication: Repeatedly checking for ERR_LOCK_WAIT_TIMEOUT (as done, for example by repeatedly executing SHOW SLAVE STATUS) during a prolonged write lock on a table led to an assert. * Replication: If statement based logging was in use, when updating multiple tables in a single statement, a single transaction could be logged as two different transactions. This was due to the binary logging process not properly identifying statements which were operating over transactional tables. The fix ensures that they are correctly identified, even if such statements do not change the contents of the tables.
2015-10-03 14:46:13 +02:00
. endif
PLIST.sphinx= yes
post-extract:
${CP} -R ${WRKDIR}/sphinx-${SPHINX_VER}-release/mysqlse ${WRKSRC}/storage/sphinx
.endif