Re: [Maria-developers] A problem with implementing Group Commit with Binlog with MyRocks

2017-09-11 Thread Kristian Nielsen
andrei.el...@pp.inet.fi writes: >> 2. To make START TRANSACTION WITH CONSISTENT SNAPSHOT actually correctly >> synchronise snapshots between multiple storage engines (MySQL does not have >> this, I think). > > (Offtopic, but anyway what it is? Multi-engine transaction with this > specific

Re: [Maria-developers] A problem with implementing Group Commit with Binlog with MyRocks

2017-09-11 Thread andrei . elkin
Kristian, Sergey, hello. While I'm still studying the Mariadb BGC (binlog group commit) let me jump in with few comments. > Sergey Petrunia writes: > >> == Some background == >> >> "group commit with binlog" feature needs to accomplish two goals: >> >> 1. Keep the binlog and

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

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

Re: [Maria-developers] A problem with implementing Group Commit with Binlog with MyRocks

2017-09-11 Thread Kristian Nielsen
Kristian Nielsen writes: > single thread. In MySQL, _both_ prepare and commits are so grouped from a > single thread (though I think one thread can do group prepare in parallel > with another doing group commit). Ehm, this is not true, of course. The prepare() calls

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 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)) { >> n_rows++; >> } >> >> It is very old

Re: [Maria-developers] A problem with implementing Group Commit with Binlog with MyRocks

2017-09-11 Thread Sergey Petrunia
Hi Kristian, On Mon, Sep 11, 2017 at 01:02:31PM +0200, Kristian Nielsen wrote: > Sergey Petrunia writes: > > > This is about https://jira.mariadb.org/browse/MDEV-11934. I've encountered > > an insteresting issue here, so I thought I would consult on both MyRocks and > >

Re: [Maria-developers] A problem with implementing Group Commit with Binlog with MyRocks

2017-09-11 Thread Kristian Nielsen
Sergey Petrunia writes: > == Some background == > > "group commit with binlog" feature needs to accomplish two goals: > > 1. Keep the binlog and the storage engine in sync. > storage_engine->prepare(sync=true); > binlog->write(sync=true); > storage_engine->commit(); > >

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

2017-09-11 Thread Sergei Golubchik
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)) { > n_rows++; > } > > It is very old (from 5.0 or earlier) and bug-prone. Because in > ha_innobase::open(): > >

[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] 2nd 2017 Developers Unconference

2017-09-11 Thread Ian Gilfillan
The dates for the Developers Unconference in Shenzhen, China, are coming up fast. This is our first official event in Asia, and will be held from 13 November - 17 November. 13 November - new contributor day 14-15 November - traditional developers unconference 16-17 November - patch days As

Re: [Maria-developers] [External] Obsolete GTID domain delete on master (MDEV-12012, MDEV-11969)

2017-09-11 Thread Simon Mudd
Hi all, > On 8 Sep 2017, at 16:48, andrei.el...@pp.inet.fi wrote: > > Kristian, hello. > > Now to the implementation matter, > >> The procedure to fix it will then be: >> >> 1. FLUSH BINARY LOGS, note the new GTID position. >> >> 2. Ensure that all slaves are past the problematic point with