On 05/15/2013 11:27 PM, Jocelyn Fournier wrote:
Hi Gordan,
Le 15/05/13 22:18, Gordan Bobic a écrit :
On 05/15/2013 09:06 PM, Michael Widenius wrote:
Hi!
"Gordan" == Gordan Bobic writes:
Gordan> How difficult would be be to implement working
Gordan> auto-increment func
On 05/15/2013 09:24 PM, Roberto Spadim wrote:
hum, maybe a 'global variable' + a 'counter' function could do the job?
select add_and_return(@global_var,1)
could return old global_var value +1, and set the global_var to +1
just a idea.. like GET_LOCK(str,timeout) do, but without timeout
How wo
On 05/15/2013 09:06 PM, Michael Widenius wrote:
Hi!
"Gordan" == Gordan Bobic writes:
Gordan> How difficult would be be to implement working
Gordan> auto-increment functionality on the BlackHole engine?
Gordan> This would be really useful for what I'm trying to d
How difficult would be be to implement working
auto-increment functionality on the BlackHole engine?
This would be really useful for what I'm trying to do at
the moment. Since it is not available and there are no
sequences in MariaDB and MySQL, I have to resort to a
hack such as a single-int-fiel
On Fri, 3 May 2013 15:07:50 +0200, Sergei Golubchik
wrote:
Hi, Honza!
On May 03, Honza Horak wrote:
Hi guys,
MariaDB forked mytop utility source some time back, but it causes
some
issues for us in Fedora for example (and similarly in other
distributions I guess) -- particularly the MariaDB'
On Fri, 26 Apr 2013 17:41:14 +0200, Reindl Harald
wrote:
* because wrapper-scripts are a bad idea on modern
linux distributions and mysqld_safe is not needed there
See below.
* because rpmbuild's automatic depsolve get useless without
* because 99 out of 100 applications have configure-swi
On Thu, 25 Apr 2013 18:29:32 +0200, Kristian Nielsen
wrote:
Daniel Bartholomew writes:
I'm getting ready to install jemalloc on the buildslaves for
TODO-459 -
https://mariadb.atlassian.net/browse/TODO-459 , and wanted to know
if
there was a preferred way to do it. Since we want to use a spe
esper Staun Hansen
wrote:
Hello Gordan,
What does your system variables look like?
What I am wondering about myself is why you're even closing the
tables.
Jesper
On 20-03-2013 14:25, Gordan Bobic wrote:
Just as an additional data point, the query does seem to eventually
complete (and th
the table being inserted into firing off. The SELECT on
it's own takes only seconds to complete. The UPDATEs fired off by the
triggers complete in milliseconds.
Gordan
On Wed, 20 Mar 2013 12:51:50 +0000, Gordan Bobic
wrote:
On Wed, 20 Mar 2013 13:20:28 +0100, Sergei Golubchik
wrote:
Hi,
On Wed, 20 Mar 2013 13:20:28 +0100, Sergei Golubchik
wrote:
Hi, Gordan!
On Mar 20, Gordan Bobic wrote:
> On Mar 20, Gordan Bobic wrote:
>> I have a situation with MariaDB 10.0.0 where an INSERT INTO ...
>> SELECT query that takes 3 seconds to run ends up stuck in the
>
On Wed, 20 Mar 2013 12:42:48 +0100, Sergei Golubchik
wrote:
Hi, Gordan!
On Mar 20, Gordan Bobic wrote:
I have a situation with MariaDB 10.0.0 where an INSERT INTO ...
SELECT query that takes 3 seconds to run ends up stuck in the
closing
tables state for 15+ minutes while burning 100% of
I have a situation with MariaDB 10.0.0 where an
INSERT INTO ... SELECT query that takes 3 seconds to run ends up
stuck in the closing tables state for 15+ minutes while burning
100% of CPU.
I have seen bug reports dating back 5 years that sound very similar
but none of them are listed as resolved
I'm having an issue with MariaDB 10.0.0. I have a bunch of
archived compressed MyISAM tables from MySQL 5.6.
I can move these around on MySQL 5.6 machines, but
when I put them on MariaDB 10.0.0 it fails to recognize them.
Has this been fixed in 10.0.1? If not, will it be fixed in 10.0.2?
Gordan
On Wed, 6 Feb 2013 11:18:36 +0100, Sergei Golubchik
wrote:
Hi, Daniel!
On Feb 06, Daniel Bartholomew wrote:
I've begun prepping MariaDB 10.0.1-alpha for release.
Preliminary changelog and release notes are here:
- https://kb.askmonty.org/en/mariadb-1001-release-notes/
- https://kb.askmonty.
On Mon, 04 Feb 2013 15:32:19 +, Gordan Bobic
wrote:
Hi,
I've just tried testing InnoDB page compression, and I'm sure
I must be doing something wrong because the disk space usage
in my database directory is the same before and after the
compression.
To compress the tables
Hi,
I've just tried testing InnoDB page compression, and I'm sure
I must be doing something wrong because the disk space usage
in my database directory is the same before and after the
compression.
To compress the tables I am using:
ALTER TABLE $table ENGINE=InnoDB ROW_FORMAT=COMPRESSED
KEY_BL
On Thu, 10 Jan 2013 14:24:32 +0100, Kristian Nielsen
wrote:
Kristian Nielsen writes:
The patch makes later transactions wait for earlier transactions to
commit
before committing themselves.
Hm, I now realise a problem with this approach :-/
The problem is with MyISAM tables, or other tabl
Hi,
I recently switched from MySQL 5.6.5 to MariaDB 10.0,
and I've been seeing errors like the following in the
logs since:
121221 13:22:34 [ERROR] Master 'master1': Found index PRIMARY whose
column info does not match that of MySQL.
121221 13:22:34 [ERROR] Master 'master1': Build InnoDB index
Hi Monty,
"Lixun" == Lixun Peng writes:
Lixun> Hi Gordan,
Lixun> I'm not changed the replicate-[do|ignore]-[table|database] functionality
Lixun> code, so I think it should work for all slave threads, but it can't
specify
Lixun> each master to use specific filter.
Yes, the replication fi
runs well.
>
> Thanks,
> Lixun
>
> Sent from my iPhone
>
> On 2012-11-29, at 下午11:38, Gordan Bobic wrote:
>
>> On 11/29/2012 02:53 PM, Sergei Golubchik wrote:
>>> Hi, Gordan!
>>>
>>> On Nov 29, Gordan Bobic wrote:
>>>> Hi,
>
On 11/29/2012 02:53 PM, Sergei Golubchik wrote:
Hi, Gordan!
On Nov 29, Gordan Bobic wrote:
Hi,
I have a need for replicating data from multiple masters (independent
data going to different tables).
...
So what I was hoping to do is write something based on the existing
MySQL code since at
Hi,
I have a need for replicating data from multiple masters (independent
data going to different tables).
I have looked into the following with no success:
Tungsten:
Slow, CPU hungry, outrageously bloated, and unacceptably unreliable
(replication will stall silently at times, and the only w
22 matches
Mail list logo
