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
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
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 &
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
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
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
> >
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();
>
>
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():
>
>
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
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
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
11 matches
Mail list logo