Re: [Maria-developers] [Commits] fb49b98: MDEV-10436 non-deterministic vcol does not force rbr
Hi, Sachin! On Jan 24, sachin wrote:
revision-id: fb49b98a85dc28846c1fdd893ff9791803873aad (mariadb-10.2.3-91-gfb49b98) parent(s): 0d107a85b3dd6969e66cc9cb4bd29e1cc92a7d18 author: Sachin Setiya committer: Sachin Setiya timestamp: 2017-01-24 17:58:23 +0530 message:
MDEV-10436 non-deterministic vcol does not force rbr
diff --git a/sql/sql_class.cc b/sql/sql_class.cc index f78382d..50d767d 100644 --- a/sql/sql_class.cc +++ b/sql/sql_class.cc @@ -5824,6 +5826,16 @@ int THD::decide_logging_format(TABLE_LIST *tables) table->table->file->ht) multi_access_engine= TRUE;
+ /* + Loop through each table field if it is virtual field check if it is deterministic + or not. + */ + for (field_ptr= table->table->field; *field_ptr; field_ptr++) + { + field= *field_ptr; + if (field->vcol_info && field->vcol_info->flags & VCOL_NOT_STRICTLY_DETERMINISTIC) + lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_NON_DETER_VCOL); + } prev_access_table= table->table; }
1. don't iterate table->table->field, use table->table->vfield - it only contains generated columns. 2. your check is too strong, in INSERT t1 VALUES (...) it does not matter if some of virtual columns are not strictly deterministic, so BINLOG_STMT_UNSAFE_NON_DETER_VCOL should not be raised. It only should be used when such a table is selected from (or in a WHERE condition of an UPDATE or DELETE). And only when such a column is used in a statement. There is nothing non-deterministing in INSERT t1 SELECT 1 FROM vcol_table 3. It might be not possible to do a per-column check, if read_set bitmaps are not ready yet. In that case, ok, do it per table, but then the result for the table is always the same, I mean where a table has not strictly deterministic columns is a property of a table. So, don't calculate it every time here, do it once and store in the TABLE_SHARE structure. Much like non_determinstic_insert is. But I'm removing non_determinstic_insert now (it's always false, dead code) so add another flag. Or - better - add a 'uint vcol_flags' member which is OR of vcol_info->flag for all fields. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi Sergei! On Wed, Jan 25, 2017 at 3:58 PM, Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Sachin!
On Jan 24, sachin wrote:
revision-id: fb49b98a85dc28846c1fdd893ff9791803873aad (mariadb-10.2.3-91-gfb49b98) parent(s): 0d107a85b3dd6969e66cc9cb4bd29e1cc92a7d18 author: Sachin Setiya committer: Sachin Setiya timestamp: 2017-01-24 17:58:23 +0530 message:
MDEV-10436 non-deterministic vcol does not force rbr
diff --git a/sql/sql_class.cc b/sql/sql_class.cc index f78382d..50d767d 100644 --- a/sql/sql_class.cc +++ b/sql/sql_class.cc @@ -5824,6 +5826,16 @@ int THD::decide_logging_format(TABLE_LIST *tables) table->table->file->ht) multi_access_engine= TRUE;
+ /* + Loop through each table field if it is virtual field check if it is deterministic + or not. + */ + for (field_ptr= table->table->field; *field_ptr; field_ptr++) + { + field= *field_ptr; + if (field->vcol_info && field->vcol_info->flags & VCOL_NOT_STRICTLY_DETERMINISTIC) + lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_NON_DETER_VCOL); + } prev_access_table= table->table; }
1. don't iterate table->table->field, use table->table->vfield - it only contains generated columns. Okay. 2. your check is too strong, in INSERT t1 VALUES (...) it does not matter if some of virtual columns are not strictly deterministic, so BINLOG_STMT_UNSAFE_NON_DETER_VCOL should not be raised. It only should be used when such a table is selected from (or in a WHERE condition of an UPDATE or DELETE). And only when such a column is used in a statement. There is nothing non-deterministing in INSERT t1 SELECT 1 FROM vcol_table yes, Now I am using table->read_set. 3. It might be not possible to do a per-column check, if read_set bitmaps are not ready yet. In that case, ok, do it per table, but then the result for the table is always the same, I mean where a table has not strictly deterministic columns is a property of a table. So, don't calculate it every time here, do it once and store in the TABLE_SHARE structure. Much like non_determinstic_insert is. But I'm removing non_determinstic_insert now (it's always false, dead code) so add another flag. Or - better - add a 'uint vcol_flags' member which is OR of vcol_info->flag for all fields.
I do not think this would be case because In newer patch "current_stmt_binlog_format" is not decide on thd->decide_logging_format (apart from the case of create table t1 as select * from vcol_table). thd->current_stmt_bionlog_format is decided on end_send function.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org Regards sachin
participants (2)
-
Sachin Setiya -
Sergei Golubchik