On Tue, 21 May 2013 19:45:02 +0300,
Michael Widenius wrote :
> This is an optimization that Heikki did a long time ago that has this
> strange side effect.
>
> See the comment posted by Radek on
> http://dev.mysql.com/doc/refman/5.5/en/delete.html
I found that a bit after posting, yes...
Is ther
Hi!
> "Vincent" == Vincent Pelletier writes:
Vincent> Hi.
Vincent> Bumping this thread with a slightly different finding which may help
Vincent> understanding the issue.
Vincent> I'll use two command lines for this test, "MariaDB 1" and "MariaDB 2",
Vincent> also distinguished by indentati
On Tue, 21 May 2013 11:35:46 +0200,
Vincent Pelletier wrote :
> I'm surprised by delete's behaviour, as I am mentally applying
> to the btree the table is.
...to the btree the table (or index) is implemented with.
> Is it just a bad assumption from my part ?
Looks like I just found part of an a
Hi.
Bumping this thread with a slightly different finding which may help
understanding the issue.
I'll use two command lines for this test, "MariaDB 1" and "MariaDB 2",
also distinguished by indentation level for readability.
Server version: 5.5.30-MariaDB-log MariaDB Server
Some setup:
Maria
Hi Kristian,
On 21/02/2013 13:31, Kristian Nielsen wrote:
>> I tried setting SERIALIZABLE isolation globally and confirmed that
>> (much) more deadlocks happened. But unfortunately "Duplicate entry"
>> error still happens.
>>
>>@@GLOBAL.tx_isolation: SERIALIZABLE
>> @
Kazuhiko Shiozaki writes:
> I tried setting SERIALIZABLE isolation globally and confirmed that
> (much) more deadlocks happened. But unfortunately "Duplicate entry"
> error still happens.
>
>@@GLOBAL.tx_isolation: SERIALIZABLE
> @@tx_isolation: SERIALIZABLE
> @@innod
Hi Kristian,
On 18/02/2013 17:38, Kazuhiko Shiozaki wrote:
> On 18/02/2013 16:59, Kristian Nielsen wrote:
It's REPEATABLE-READ.
>>>
>>> And innodb_locks_unsafe_for_binlog is ON, could it be the reason ?
>>
>> Yes.
> (snip)
>> With --innodb-locks-unsafe-for-binlog=0, the DELETE from connectio
Hi Kristian,
On 18/02/2013 16:59, Kristian Nielsen wrote:
>>> It's REPEATABLE-READ.
>>
>> And innodb_locks_unsafe_for_binlog is ON, could it be the reason ?
>
> Yes.
(snip)
> With --innodb-locks-unsafe-for-binlog=0, the DELETE from connection A waits
> for a next-key lock set by the DELETE in B,
Kazuhiko Shiozaki writes:
>> It's REPEATABLE-READ.
>
> And innodb_locks_unsafe_for_binlog is ON, could it be the reason ?
Yes.
A> SELECT @@global.innodb_locks_unsafe_for_binlog;
@@global.innodb_locks_unsafe_for_binlog
1
A> SET SESSION TRANSACTION ISOLATION LEVEL REPEATA
On 18/02/2013 16:31, Kazuhiko Shiozaki wrote:
> On 18/02/2013 15:36, Kristian Nielsen wrote:
>>> We sometimes (not always, not often but sometimes) have unexpected
>>> "Duplicate entry" error on the following table and with the following
>>> query :
>>>
>>> BEGIN;
>>>
>>> (some queries for other ta
Hi Krisian,
On 18/02/2013 15:36, Kristian Nielsen wrote:
>> We sometimes (not always, not often but sometimes) have unexpected
>> "Duplicate entry" error on the following table and with the following
>> query :
>>
>> BEGIN;
>>
>> (some queries for other tables)
>>
>> DELETE FROM category WHERE uid
Kazuhiko Shiozaki writes:
> We sometimes (not always, not often but sometimes) have unexpected
> "Duplicate entry" error on the following table and with the following
> query :
>
> BEGIN;
>
> (some queries for other tables)
>
> DELETE FROM category WHERE uid=14026268;
>
> INSERT INTO category VAL
Hello,
We sometimes (not always, not often but sometimes) have unexpected
"Duplicate entry" error on the following table and with the following
query :
* table
CREATE TABLE `category` (
`uid` bigint(20) unsigned NOT NULL,
`category_uid` bigint(20) unsigned NOT NULL DEFAULT '0',
`base_categ
13 matches
Mail list logo
