[MDEV-5231] Per query variables from Percona Server [patch] - Jira

Details

Type: Task
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Fix Version/s: 10.1.2
Component/s: OTHER
Labels:
None

Description

Port of per query variables feature from Percona Server. Allows changing variables for duration of the query.
docs: http://www.percona.com/doc/percona-server/5.6/flexibility/per_query_variable_statement.html
commit in PS: http://bazaar.launchpad.net/~percona-core/percona-server/5.6/revision/477

patch for mariadb 10.0: http://bazaar.launchpad.net/~pomyks/maria/10.0-per-query-variables/revision/3880

Attachments

Issue Links

blocks

MDEV-4427 query timeouts

Closed

duplicates

MDEV-5251 SET STATEMENT feature

Closed

relates to

MDEV-6940 SET STATEMENT executed after SET GLOBAL does not work

Closed

MDEV-6941 SET STATEMENT affects the value of the GLOBAL variable for the duration of the statement

Closed

MDEV-6942 SET SESSION statement combined with SET STATEMENT has no effect if it's executed for the same variable

Closed

MDEV-6944 SQL_MODEs related to parsing are not applied during execution of the actual statement under SET STATEMENT .. FOR

Closed

MDEV-6945 SET STATEMENT autocommit=... has no effect and causes warnings in the error log

Closed

MDEV-6946 Assertion `0' failed in mysql_execute_command on SET STATEMENT keycache1.key_buffer_size=.. FOR

Closed

MDEV-6948 SET STATEMENT gtid_domain_id = ... FOR has no effect (same for gtid_seq_no and server_id)

Closed

MDEV-6949 MySQL client does not recognize SET STATEMENT .. FOR USE <db name> as a schema change

Closed

MDEV-6951 Erroneous SET STATEMENT produces two identical errors

Closed

MDEV-6953 SET STATEMENT profiling = .. FOR does not have any effect

Closed

MDEV-6954 SET STATEMENT rand_seedX = ...FOR ... makes the next rand() to return 0

Closed

MDEV-6955 SET STATEMENT tx_isolation = FOR ... inside a transaction is meaningless and cannot have any effect, but is allowed

Closed

MDEV-6956 SET STATEMENT default_master_connection = ... has no effect

Closed

MDEV-6957 SET STATEMENT skip_replication = .. makes the binary log non-replayable

Closed

MDEV-6976 Assertion `! is_set() || m_can_overwrite_status' failed in Diagnostics_area::set_error_status on SET STATEMENT debug_sync

Closed

MDEV-6977 SET STATEMENT query_cache_type apparently has no effect and hence should be disallowed

Closed

MDEV-6996 SET STATEMENT default_week_format = .. has no effect

Closed

MDEV-6997 SET STATEMENT last_insert_id FOR ... does not affect the value written to the binlog

Closed

MDEV-7002 SET STATEMENT sql_log_off has no effect

Closed

MDEV-7006 SET STATEMENT does not work with slow log tuning (long_query_time, log_slow_filter, log_slow_verbosity, log_slow_rate_limit)

Closed

MDEV-7007 SET STATEMENT slow_query_log has no effect

Closed

MDEV-7009 SET STATEMENT min_examined_row_limit has no effect

Closed

MDEV-7012 SET STATEMENT character_set_client, character_set_connection, character_set_filesystem, collation_connection have no effect

Closed

MDEV-7013 SET STATEMENT wait_timeout or interactive_timeout seem meaningless

Closed

MDEV-7015 SET STATEMENT old_passwords has no effect

Closed

MDEV-7018 SET STATEMENT query_response_time_exec_time_debug has no effect

Closed

MDEV-27462 SET STATEMENT allows variables that cannot be set per query basis

Stalled

links to

GSoC 2009 Project tree

Merge request

MySQL WL#681

Percona Server patch

(24 relates to, 4 links to)

Activity

Ascending order - Click to sort in descending order

Oleksandr Byelkin added a comment - 2014-02-20 11:04

10.0 patch applied with no problem on 10.1.
2 issue to check so far:
1) if saving/restoring variables values could be optimized
2) increasing conflicts in the parser

Oleksandr Byelkin added a comment - 2014-02-20 11:04 10.0 patch applied with no problem on 10.1. 2 issue to check so far: 1) if saving/restoring variables values could be optimized 2) increasing conflicts in the parser

Oleksandr Byelkin added a comment - 2014-02-20 17:48

mem_root memory should be used for allocation instead of my_malloc. Time of live of variables backup is statement and mem_root should be faster.

Oleksandr Byelkin added a comment - 2014-02-20 17:48 mem_root memory should be used for allocation instead of my_malloc. Time of live of variables backup is statement and mem_root should be faster.

Oleksandr Byelkin added a comment - 2014-02-20 18:05

Result of any alloc should be checked before assigning something by this address.

Oleksandr Byelkin added a comment - 2014-02-20 18:05 Result of any alloc should be checked before assigning something by this address.

Oleksandr Byelkin added a comment - 2014-02-20 18:23 - edited

What if a variable with some side-effect changed? (are there such variables among session one).

Oleksandr Byelkin added a comment - 2014-02-20 18:23 - edited What if a variable with some side-effect changed? (are there such variables among session one).

Oleksandr Byelkin added a comment - 2014-02-20 18:38

update called on restoring which is OK

Oleksandr Byelkin added a comment - 2014-02-20 18:38 update called on restoring which is OK

Oleksandr Byelkin added a comment - 2014-02-21 10:28

As far as all variables copied in one chunk (two if there is dynamic). There is no gain in copy of only changed.

But first call of malloc (backup of THD variables) changed with sql_alloc because it should not live over statement execution.

Both memory allocation results checked and error returned in case of EOM.

Oleksandr Byelkin added a comment - 2014-02-21 10:28 As far as all variables copied in one chunk (two if there is dynamic). There is no gain in copy of only changed. But first call of malloc (backup of THD variables) changed with sql_alloc because it should not live over statement execution. Both memory allocation results checked and error returned in case of EOM.

Oleksandr Byelkin added a comment - 2014-02-21 10:34

Deallocation items before mysql_sql_stmt_execute() call looks suspicious.

Oleksandr Byelkin added a comment - 2014-02-21 10:34 Deallocation items before mysql_sql_stmt_execute() call looks suspicious.

Oleksandr Byelkin added a comment - 2014-02-21 13:05

Yes. It was unclean items from setting variables. So it should be done in other place.

Oleksandr Byelkin added a comment - 2014-02-21 13:05 Yes. It was unclean items from setting variables. So it should be done in other place.

Oleksandr Byelkin added a comment - 2014-02-21 13:06

Above rise question which memory execution of setting variables run on.

Oleksandr Byelkin added a comment - 2014-02-21 13:06 Above rise question which memory execution of setting variables run on.

Oleksandr Byelkin added a comment - 2014-02-21 13:53

The place of item list is correct (only EXECUTION prepared statement need it) but comment changed on more correct.

Arena checked and it is correct (DBUG_ASSERT put there).

Oleksandr Byelkin added a comment - 2014-02-21 13:53 The place of item list is correct (only EXECUTION prepared statement need it) but comment changed on more correct. Arena checked and it is correct (DBUG_ASSERT put there).

Oleksandr Byelkin added a comment - 2014-02-21 13:55

Is everything ok with SP?..

Oleksandr Byelkin added a comment - 2014-02-21 13:55 Is everything ok with SP?..

Oleksandr Byelkin added a comment - 2014-02-24 09:44

Subqueries in the variables expressions?

Oleksandr Byelkin added a comment - 2014-02-24 09:44 Subqueries in the variables expressions?

Oleksandr Byelkin added a comment - 2014-02-24 10:11

CREATE TABLE t1 (v1 INT, v2 INT);
INSERT INTO t1 VALUES (1,2);
INSERT INTO t1 VALUES (3,4);

PREPARE stmt2
FROM 'SELECT * FROM t1';
SET STATEMENT myisam_sort_buffer_size=400000,
myisam_repair_threads=(select max(v1) from t1),
sort_buffer_size=200000,
binlog_format=row,
keep_files_on_create=OFF,
max_join_size=4444440000000 FOR
EXECUTE stmt2;

crash in the original patch.

Oleksandr Byelkin added a comment - 2014-02-24 10:11 CREATE TABLE t1 (v1 INT, v2 INT); INSERT INTO t1 VALUES (1,2); INSERT INTO t1 VALUES (3,4); PREPARE stmt2 FROM 'SELECT * FROM t1'; SET STATEMENT myisam_sort_buffer_size=400000, myisam_repair_threads=(select max(v1) from t1), sort_buffer_size=200000, binlog_format=row, keep_files_on_create=OFF, max_join_size=4444440000000 FOR EXECUTE stmt2; crash in the original patch.

Patryk Pomykalski added a comment - 2014-04-17 16:35

Percona Server 5.6.16 also crashes.

Patryk Pomykalski added a comment - 2014-04-17 16:35 Percona Server 5.6.16 also crashes.

Oleksandr Byelkin added a comment - 2014-05-22 15:56

The patch sent for review.

Oleksandr Byelkin added a comment - 2014-05-22 15:56 The patch sent for review.

Oleksandr Byelkin added a comment - 2014-06-24 16:05

https://bugs.launchpad.net/percona-server/+bug/1333650

Oleksandr Byelkin added a comment - 2014-06-24 16:05 https://bugs.launchpad.net/percona-server/+bug/1333650

Oleksandr Byelkin added a comment - 2014-07-10 14:53

Above fixed

Oleksandr Byelkin added a comment - 2014-07-10 14:53 Above fixed