Hi, Sachin!
On Mar 12, Sachin Setiya wrote:
> revision-id: 1aa6d5bdbec (mariadb-10.4.3-63-g1aa6d5bdbec)
> parent(s): b5d2e8577ef
> author: Sachin Setiya
> committer: sachin
> timestamp: 2019-03-12 19:29:58 +0530
> message:
>
> MDEV-1 Server crashes in Item_field::register_field_in_read_map
Hi, Sachin!
On Mar 12, Sachin Setiya wrote:
> revision-id: b5d2e8577ef (mariadb-10.4.3-62-gb5d2e8577ef)
> parent(s): 202d1b0c897
> author: Sachin Setiya
> committer: sachin
> timestamp: 2019-03-12 19:29:58 +0530
> message:
>
> MDEV-18889 Long unique on virtual fields crashes server
>
> When we
Hi, Sachin!
On Mar 12, Sachin Setiya wrote:
> revision-id: 003abb6d9dc (mariadb-10.4.3-58-g003abb6d9dc)
> parent(s): e2f8f968785
> author: sachin
> committer: sachin
> timestamp: 2019-03-12 19:29:57 +0530
> message:
>
> MDEV-18799 Long unique does not work after failed alter table
>
> Restore
Hi, Sachin!
On Mar 12, Sachin Setiya wrote:
> revision-id: 202d1b0c897 (mariadb-10.4.3-61-g202d1b0c897)
> parent(s): a4b8e0c30d1
> author: sachin
> committer: sachin
> timestamp: 2019-03-12 19:29:58 +0530
> message:
>
> MDEV-18809 Server crash in fields_in_hash_keyinfo or Assertion...
> `key_in
Hi, Sachin!
ok to push
On Mar 12, Sachin Setiya wrote:
> revision-id: a4b8e0c30d1 (mariadb-10.4.3-60-ga4b8e0c30d1)
> parent(s): d8e4463d5dc
> author: sachin
> committer: sachin
> timestamp: 2019-03-12 19:29:57 +0530
> message:
>
> MDEV-18800 Server crash in instant_alter_column_possible or Ass
Hi, Sachin!
Ok to push, just one minor detail, see below
On Mar 12, Sachin Setiya wrote:
> revision-id: e2f8f968785 (mariadb-10.4.3-57-ge2f8f968785)
> parent(s): 6d68a3464e9
> author: sachin
> committer: sachin
> timestamp: 2019-03-12 19:29:57 +0530
> message:
>
> MDEV-18790 Server crash in fi
Hi, Aleksey!
On Mar 12, Aleksey Midenkov wrote:
> Hi, Sergei,
>
> Thank you for observations! This task is in progress. While doing it I
> found out that RBR doesn't replicate timestamp fractions. That is: it
> gets seconds from event timestamp marker and adds fractions from
> system time. This
Hi Jocelyn,
On Tue, Mar 12, 2019 at 5:50 PM jocelyn fournier
wrote:
> Hi Sergei!
>
> Just wondering why keeping the toku_ prefix after renaming toku_* to
> toku_external_* since it’s also used by other engine like RockDB?
>
> My intent with using similar names was to show that the API is mimicki
Hi Sergei!
Just wondering why keeping the toku_ prefix after renaming toku_* to
toku_external_* since it’s also used by other engine like RockDB?
BR,
Jocelyn Fournier
> Le 12 mars 2019 à 09:52, Sergei Petrunia a écrit :
>
> revision-id: 190a29d06f4e79d2df4cb513944ac34bd133caa0 (v5.8-1024-g
Aleksey, hello.
> Hi, Sergei,
>
> Thank you for observations! This task is in progress. While doing it I found
> out that RBR doesn't replicate timestamp fractions.
> That is: it gets seconds from event timestamp marker and adds fractions from
> system time. This causes bugs in System Versioning
Hi, Sergei,
Thank you for observations! This task is in progress. While doing it I
found out that RBR doesn't replicate timestamp fractions. That is: it gets
seconds from event timestamp marker and adds fractions from system time.
This causes bugs in System Versioning. More on it in Bug 6 here:
ht
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() updates blob
> buffer and frees the old one. Then ha_partition::return_top_record()
> returns record from m_ord
12 matches
Mail list logo
