Re: [Maria-developers] set_time() on slave and unversioned -> versioned replication

2019-04-04 Thread Aleksey Midenkov
On Thu, Apr 4, 2019 at 5:08 PM Sergei Golubchik wrote: > Hi, Aleksey! > > On Apr 04, Aleksey Midenkov wrote: > > On Thu, Apr 4, 2019 at 2:43 PM Sergei Golubchik > wrote: > > > > > If there is an installation from unversioned 5.3 to versioned 10.3 we > >

Re: [Maria-developers] set_time() on slave and unversioned -> versioned replication

2019-04-04 Thread Aleksey Midenkov
On Thu, Apr 4, 2019 at 2:43 PM Sergei Golubchik wrote: > Hi, Aleksey! > > On Apr 04, Aleksey Midenkov wrote: > > Hello, Sergei! > > > > In unversioned -> versioned scenario in the code below it first gets to > Set > > time 4, creates some records (on slave

[Maria-developers] set_time() on slave and unversioned -> versioned replication

2019-04-04 Thread Aleksey Midenkov
e", print_start_time("Set time 4");); } user_time.val= hrtime_from_time(start_time) + start_time_sec_part; PSI_CALL_set_thread_start_time(start_time); start_utime= utime_after_lock= microsecond_interval_timer(); } } -- All the best, Aleksey Midenkov @

Re: [Maria-developers] 9976699033c: Test fixes (versioning.replace, versioning.foreign)

2019-03-31 Thread Aleksey Midenkov
Hi Sergei! On Wed, Mar 27, 2019 at 6:08 PM Sergei Golubchik wrote: > Hi, Aleksey! > > On Mar 27, Aleksey Midenkov wrote: > > revision-id: 9976699033c (mariadb-10.3.7-30-g9976699033c) > > parent(s): c0f97710582 > > author: Aleksey Midenkov > > committer: Aleksey

Re: [Maria-developers] ab6ef429a84: MDEV-16370 row-based binlog events (updates by primary key) can not be applied multiple times to system versioned tables

2019-03-29 Thread Aleksey Midenkov
Hi Sergei! On Wed, Mar 13, 2019 at 7:16 PM Sergei Golubchik wrote: > Hi, Aleksey! > > On Jan 31, Aleksey Midenkov wrote: > > revision-id: ab6ef429a84 (versioning-1.0.7-2-gab6ef429a84) > > parent(s): 14c2f90ad08 > > author: Aleksey Midenkov > > committer: Alek

[Maria-developers] THD::set_time()

2019-03-28 Thread Aleksey Midenkov
What if system_time.sec_part == TIME_MAX_SECOND_PART here: else { start_time= t; start_time_sec_part= ++system_time.sec_part; } ? -- All the best, Aleksey Midenkov @midenok ___ Mailing list: https://launchpad.net

Re: [Maria-developers] 74b2eba1ca6: MDEV-15458 Segfault in heap_scan() upon UPDATE after ADD SYSTEM VERSIONING

2019-03-27 Thread Aleksey Midenkov
Hi, Sergei! On Wed, Mar 27, 2019 at 1:04 AM Sergei Golubchik wrote: > Hi, Aleksey! > > On Mar 26, Aleksey Midenkov wrote: > > revision-id: 74b2eba1ca6 (mariadb-10.3.12-115-g74b2eba1ca6) > > parent(s): 2c0901d808b > > author: Aleksey Midenkov > > committer: Serg

Re: [Maria-developers] MDEV-18734 ASAN heap-use-after-free in my_strnxfrm_simple_internal upon update on versioned partitioned table

2019-03-25 Thread Aleksey Midenkov
Hi Sergei, On Thu, Mar 21, 2019 at 10:24 PM Sergei Golubchik wrote: > Hi, Aleksey! > > On Mar 20, Aleksey Midenkov wrote: > > Hi Sergei! > > > > It turned out that only vcol blobs are affected. They are allocated > > by update_virtual_fields(), so it was e

Re: [Maria-developers] MDEV-18734 ASAN heap-use-after-free in my_strnxfrm_simple_internal upon update on versioned partitioned table

2019-03-20 Thread Aleksey Midenkov
/1234 On Tue, Mar 12, 2019 at 1:42 PM Sergei Golubchik wrote: > Hi, Aleksey! > > On Mar 11, Aleksey Midenkov wrote: > > Hi, Sergei! > > > > ha_partition::handle_ordered_index_scan() stores records in > > m_ordered_rec_buffer. Then TABLE::update_virtual_fields()

Re: [Maria-developers] ASAN segfaults on vcol case

2019-03-18 Thread Aleksey Midenkov
ot immediately recognize what > might be wrong in mysqltest.cc. Maybe there is some macro obfuscation > at play. > > Marko > > On Mon, Mar 18, 2019 at 4:59 PM Aleksey Midenkov > wrote: > > > > This case segfaults in ASAN code: > > > > delimiter ~

[Maria-developers] ASAN segfaults on vcol case

2019-03-18 Thread Aleksey Midenkov
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

Re: [Maria-developers] 14c2f90ad08: Idempotent INSERT events for system versioning

2019-03-13 Thread Aleksey Midenkov
Sergey, On Wed, Mar 13, 2019 at 9:48 PM Sergei Golubchik wrote: > Hi, Aleksey! > > On Mar 13, Aleksey Midenkov wrote: > > On Wed, Mar 13, 2019 at 9:01 PM Sergei Golubchik > wrote: > > > On Mar 13, Aleksey Midenkov wrote: > > > > > > > > > &

Re: [Maria-developers] 14c2f90ad08: Idempotent INSERT events for system versioning

2019-03-13 Thread Aleksey Midenkov
Sergei, On Wed, Mar 13, 2019 at 9:01 PM Sergei Golubchik wrote: > Hi, Aleksey! > > On Mar 13, Aleksey Midenkov wrote: > > > > > > Query_log_event() can already store microseconds, see Q_HRNOW flag. > > > So better to add them to Rows_log_event, if n

Re: [Maria-developers] 14c2f90ad08: Idempotent INSERT events for system versioning

2019-03-13 Thread Aleksey Midenkov
Andrei, thanks for explanation! Agree with you and Sergei on that topic. Sergei, On Tue, Mar 12, 2019 at 9:04 PM Sergei Golubchik wrote: > Hi, Aleksey! > > On Mar 12, Aleksey Midenkov wrote: > > Hi, Sergei, > > > > Thank you for observations! This task is in

Re: [Maria-developers] 14c2f90ad08: Idempotent INSERT events for system versioning

2019-03-12 Thread Aleksey Midenkov
lag LOG_EVENT_HAS_SEC_PART_F (for support sending Log_event without fractions). Do you agree? On Thu, Jan 31, 2019 at 1:10 PM Sergei Golubchik wrote: > Hi, Aleksey! > > On Jan 31, Aleksey Midenkov wrote: > > revision-id: 14c2f90ad08 (versioning-1.0.7-1-g14c2f90ad08) > > parent(s): a8efe7ab1f2 >

[Maria-developers] MDEV-18734 ASAN heap-use-after-free in my_strnxfrm_simple_internal upon update on versioned partitioned table

2019-03-11 Thread Aleksey Midenkov
with this? I propose to duplicate blob buffer when record gets into m_ordered_rec_buffer. More details can be found here: https://github.com/tempesta-tech/mariadb/issues/581 -- All the best, Aleksey Midenkov @midenok ___ Mailing list: https

Re: [Maria-developers] 7198e7c71fc: MDEV-15458 Segfault in heap_scan() upon UPDATE after ADD SYSTEM VERSIONING

2018-12-27 Thread Aleksey Midenkov
Hi! On Tue, Dec 25, 2018 at 1:27 PM Sergei Golubchik wrote: > > Hi, Aleksey! > > On Dec 23, Aleksey Midenkov wrote: > > revision-id: 7198e7c71fc (versioning-1.0.6-82-g7198e7c71fc) > > parent(s): 6be155757b7 > > author: Aleksey Midenkov > > committer: Aleksey

Re: [Maria-developers] Dead code in class sp_head

2018-06-26 Thread Aleksey Midenkov
Alexander, this is leftover after MDEV-15991, so please feel free to fix. Sorry for the inconvenience! On Mon, Jun 25, 2018 at 7:50 AM, Alexander Barkov wrote: > Hi Aleksey, > > I found some dead code in sp_head that seem to have appeared > in your patch for "IB: 0.2 part IV". > > If you don't

Re: [Maria-developers] Questions about AS OF (possibly bugs found)

2018-04-11 Thread Aleksey Midenkov
ype later. > > this is clearly a bug too. > >> I propose >> 1. Either we fix the code to call resolve_unit() in fixed state. >> 2. Or, if it's too hard, at least temporary disallow hybrid data type >> Items to be used in AS OF. >> >> Is N1 doa

Re: [Maria-developers] Dead code Type_handler_hybrid_field_type::m_vers_trx_id ?

2018-04-10 Thread Aleksey Midenkov
Hi Alexander! On Tue, Apr 10, 2018 at 12:15 PM, Alexander Barkov wrote: > Hi Aleksey, > > You added Type_handler_hybrid_field_type::m_vers_trx_id. > > Is it really needed? It seems to be always "false". > So this code in aggregate_for_comparison() seems to be a dead code: > >

Re: [Maria-developers] IB: trx_t:: start_time and start_time_micro

2017-11-21 Thread Aleksey Midenkov
, not the relative one like it is now. -- All the best, Aleksey Midenkov @midenok > > I shortly discussed this with Vladislav Vaintroub, and he mentioned that the > microsecond timestamp in THD::start_utime is updated at the start of each > statement. > I also looked at his MDEV-123

[Maria-developers] IB: trx_t:: start_time and start_time_micro

2017-11-16 Thread Aleksey Midenkov
t_time` or it should be explicitly commented that it has nothing to do with `start_time`. I.e. there is nothing wrong on algorithmic level, but such data members may (and certainly would) lead developers to misuse of `start_time_micro`. -- All the best, Aleksey Midenkov @m

Re: [Maria-developers] Code syntax: questions on pointers, etc.

2017-10-23 Thread Aleksey Midenkov
On Sun, Oct 22, 2017 at 10:27 PM, Sergei Golubchik <s...@mariadb.org> wrote: > Hi, Aleksey! > > On Oct 20, Aleksey Midenkov wrote: >> Recent refactorings of replacing C strings with LEX_CSTRING which is >> no doubt a good thing raise some questions: >> >&g

Re: [Maria-developers] MDEV-13550 is test case required?

2017-10-14 Thread Aleksey Midenkov
Sergei, On Sat, Oct 14, 2017 at 9:20 PM, Sergei Golubchik <s...@mariadb.org> wrote: > Hi, Aleksey! > > On Oct 13, Aleksey Midenkov wrote: >> Hello! >> >> Do we have to write test cases for such coding errors? Because this is >> developer factor:

[Maria-developers] MDEV-13550 is test case required?

2017-10-13 Thread Aleksey Midenkov
Hello! Do we have to write test cases for such coding errors? Because this is developer factor: either he does such errors or not. What are conditions of getting PR merged? ___ Mailing list: https://launchpad.net/~maria-developers Post to :

Re: [Maria-developers] ha_innobase::info_low() n_rows hack

2017-09-11 Thread Aleksey Midenkov
Hello! On Mon, Sep 11, 2017 at 4:37 PM, Sergei Golubchik <s...@mariadb.org> wrote: > Hi, Aleksey! > > On Sep 11, Aleksey Midenkov wrote: >> In ha_innobase::info_low() there is following dirty hack: >> >> if (n_rows == 0 && !(flag & HA_STATUS_TIME)) { &

[Maria-developers] ha_innobase::info_low() n_rows hack

2017-09-11 Thread Aleksey Midenkov
In ha_innobase::info_low() there is following dirty hack: /* The MySQL optimizer seems to assume in a left join that n_rows is an accurate estimate if it is zero. Of course, it is not, since we do not have any locks on the rows yet at this phase. Since SHOW TABLE STATUS seems to call this

[Maria-developers] HAVE_LONG_LONG check

2017-07-20 Thread Aleksey Midenkov
Do we need HAVE_LONG_LONG in item.cc: #ifdef HAVE_LONG_LONG case MYSQL_TYPE_LONGLONG: field= new (mem_root) Field_longlong((uchar*) 0, max_length, null_ptr, 0, Field::NONE, name, 0, unsigned_flag); break; #endif ? There is no such check in field.cc: case

<    1   2