Hi Sergei!
On Wed, Jan 25, 2017 at 3:58 PM, Sergei Golubchik <s...@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 secur...@mariadb.org
Regards
sachin
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
