Re: [Maria-developers] 7d593466a22: MDEV-20015 Assertion `!in_use->is_error()' failed in TABLE::update_virtual_field

[Aleksey Midenkov]

Hi, Sergei!

I tried variations of second and third options. The
gcol.gcol_keys_innodb depends on the return status and error code
thrown. It turns out that simplest solution is to use
Counting_error_handler alone.

The updated patch is

cd9cab54aac56f0f0171fa661fedffdbb4915edf (bb-10.2-midenok)

On Thu, Apr 23, 2020 at 2:48 PM Sergei Golubchik  wrote:
>
> Hi, Aleksey!
>
> I don't see what you've changed. We've discussed that fix and that one
> isn't supposed to swap Diagnostics_area's like that. And in your new
> patch you do exactly the same.
>
> Possible correct approaches:
>
> * don't return in_use->is_error(), return the return value of
>   vf->vcol_info->expr->walk() || vf->vcol_info->expr->save_in_field()
>   This means that Item_field::update_vcol_processor() should also
>   do the same, I suspect
>
> * Use thd->push_internal_handler() and Counting_error_handler.
>   Or, better, Turn_errors_to_warnings_handler with counting.
>   This is the simplest one.
>
> there's a third option:
>
> * always return 0, because, looking how it's used, I don't really see
>   how update_virtual_field() can ever get an error. But it's not a
>   particularly future-proof approach. And I just might be wrong about
>   errors.
>
> On Apr 23, Aleksey Midenkov wrote:
> > revision-id: 7d593466a22 (mariadb-10.2.28-4-g7d593466a22)
> > parent(s): 7bc26de591c
> > author: Aleksey Midenkov 
> > committer: Aleksey Midenkov 
> > timestamp: 2019-11-07 10:45:21 +0300
> > message:
> >
> > MDEV-20015 Assertion `!in_use->is_error()' failed in 
> > TABLE::update_virtual_field
> >
> > Preserve and restore statement DA.
> >
> > update_virtual_field() is called as part of index rebuild in
> > ha_myisam::repair() (MDEV-5800) which is done on bulk INSERT finish.
> >
> > Assertion in update_virtual_field() was put as part of MDEV-16222
> > because update_virtual_field() returns in_use->is_error(). The idea:
> > wrongly mixed semantics of error status before update_virtual_field()
> > and the status returned by update_virtual_field(). The former can
> > falsely influence the latter.
> >
> > Preserve global error status and run update_virtual_field() with clear
> > DA since no matter how SQL command is finished it must update the
> > index after bulk INSERT.
> >
> Regards,
> Sergei
> VP of MariaDB Server Engineering
> and secur...@mariadb.org



--
All the best,

Aleksey Midenkov
@midenok

___
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

[Maria-developers] Progress Report - Week 3

[Mohammed Hammaad Mateen]

Greetings,
Hope you are safe and doing great,

This post describes the things I've done in my third week [ 18-24 May ] of
Community Bonding Period under the mentor-ship of Sergei Golubchik and
Oleksandr Byelkin for GSoC-20. The tasks taken up for this week was to
study and analyze:

*INSERT RETURNING:*
• *TableList* consists of 1 table instance to use, where each instance is a
structure consisting of db argument, table name argument, alias argument
and lock type argument. *Referenced this from the table.h file.*
• In *sql_parse.cc*  under *case SQLCOM_INSERT*:
   we do a DBUG_ASSERT where first_table == all_table && first_table!=0 //
we check if only 1 table is used and the table used is already created.
• if lex-> has_returning() we increment the system status var by 1 and
perform analyze.. insert.. returning.
• we compute result by mysql_insert function by passing the following
arguments.
- Thread Handler thd
- all table instances
- list of all the fields used
- the values we want to insert
- the list of update feilds
- and update value list
- duplicate flag
- ignore
- result of select
• if Inserting fails due to some reason we equate result to
send_explain(thd)
• we also update the MYSQL_INSERT_DONE with result of insert and the the
row count.

*INSERT.. SELECT.. RETURNING:*
• We fix the lock on first table.
• lock other tables until command is written to the binary log.
• the procedure is same as discussed earlier with respect to insert
returning.
• To switch to the second table we traverse from first_table to (->)
next_local and we compute select result with the help of select insert
function.
• we can now unlock the tables and we also need to check if something
changed after unlocking, of that happens we should invalidate the table
from the query cache using query_cache_invalidate3 function.
• Manual cleaning of select result obtained from select insert must be done.

Regards,
Mohammed Hammaad Mateen
___
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