Hi...
As I understand mysql, Innodb provides for row level locking, as opposed to
myIsam which does tbl level locking. Is this correct?
If I am correct, if I have a trigger on a Innodb tbl (foo), such that the
trigger then copies a row to another innodb tbl (cat), foo should only do a
lock of the
sujay
-Original Message-
From: Tony Leake [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 05, 2005 7:55 PM
To: Sujay Koduri
Cc: mysql@lists.mysql.com
Subject: RE: innodb locking
On Wed, 2005-10-05 at 07:12 -0700, Sujay Koduri wrote:
> Is this happening every time you try this, or it
Tony Leake wrote:
Hi,
I have a query:
UPDATE dbseXyzOrders.tblOrder SET intPoUid = 98 WHERE intOrderUid =
10798
intOrderUid is the primary key
There are 25 columns in the table and a further 8 of these have indexes
on them. The table is innodb
I have just tried to run the above query 3
I have ever meet this problem, however i never found best solutions.
Make sure that there're no other session that update the data with
AUTOCOMMIT=0
If there's another session with autocommi=0 and update the data, kill it
first so your session will not timeout lock
use SHOW INNODB STATUS to s
> Sent: Wednesday, October 05, 2005 7:27 PM
> To: mysql@lists.mysql.com
> Subject: innodb locking
>
> Hi,
>
> I have a query:
>
> UPDATE dbseXyzOrders.tblOrder SET intPoUid = 98 WHERE intOrderUid =
> 10798
>
> intOrderUid is the primary key
>
> T
update. (can't find from thet if it is the same row or not)
Also can you please tell what isolation level are you using now.
sujay
-Original Message-
From: Tony Leake [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 05, 2005 7:27 PM
To: mysql@lists.mysql.com
Subject: innodb lockin
Hi,
I have a query:
UPDATE dbseXyzOrders.tblOrder SET intPoUid = 98 WHERE intOrderUid =
10798
intOrderUid is the primary key
There are 25 columns in the table and a further 8 of these have indexes
on them. The table is innodb
I have just tried to run the above query 3 times and i got the
Hi,
I'm running quite a large database - mostly inserts (4-5 million rows a day)
and an occasional select to generate some report based on the inserted data
which works very well.
Once a month I need to generate a larger number of reports. The SELECT queries
are optimized quite well but some of
From: "Sean"
> on the page http://dev.mysql.com/doc/mysql/en/InnoDB_Locks_set.html
>
> This statement is confusing.
>
> "If you do not have indexes suitable for your query and MySQL has to scan
the whole table to process the query, every row of the table will become
locked"
>
> Is it saying that
on the page http://dev.mysql.com/doc/mysql/en/InnoDB_Locks_set.html
This statement is confusing.
"If you do not have indexes suitable for your query and MySQL has to scan the
whole table to process the query, every row of the table will become locked"
Is it saying that all at once at the beg
Alex,
- Original Message -
From: ""Zeltser, Alex"" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Wednesday, January 21, 2004 10:28 PM
Subject: RE: InnoDB locking 'non-existence' of a row
> Hello Heikki,
>
> Thank you for y
,
Alex Zeltser
List: MySQL General Discussion < Previous MessageNext Message >
From: Heikki Tuuri Date: January 21 2004 4:32am
Subject: Re: InnoDB locking 'non-existence' of a row
Alex,
diagram:
record1 'gap' record2
(User A holds a next-key
Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM
tables
Order MySQL technical support from https://order.mysql.com/
- Original Message -
From: ""Zeltser, Alex"" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Tuesday, January 20,
iginal Message-
From: Joe Shear [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 20, 2004 11:00 AM
To: Zeltser, Alex
Cc: [EMAIL PROTECTED]
Subject: RE: InnoDB locking 'non-existence' of a row
hi,
Selecting a non-existent row won't acquire any locks that prevents inserts from
hap
re any way to make the second session block when both it and the first one are
> 'locking'
> non-existence of a row?
>
> Thanks in advance,
>
> Alex
>
> -Original Message-
> From: Chris Nolan [mailto:[EMAIL PROTECTED]
> Sent: Friday, Janua
day, January 16, 2004 4:55 PM
To: Zeltser, Alex
Cc: [EMAIL PROTECTED]
Subject: Re: InnoDB locking 'non-existence' of a row
Hi Alex!
On Sat, 2004-01-17 at 05:50, Zeltser, Alex wrote:
> Hi,
>
> I wanted to take advantage of the InnoDB 'gap' locking to lock
> '
Hi Alex!
On Sat, 2004-01-17 at 05:50, Zeltser, Alex wrote:
> Hi,
>
> I wanted to take advantage of the InnoDB 'gap' locking to lock 'non-existence' of a
> row, the way the
> manual recommends. I tried to do this by using 'select ... for update', using the
> 'mysql' client
> from two separate s
Hi,
I wanted to take advantage of the InnoDB 'gap' locking to lock 'non-existence' of a
row, the way the
manual recommends. I tried to do this by using 'select ... for update', using the
'mysql' client
from two separate sessions as shown below:
Session 1:
> set AUTOCOMMIT=0;
> begin;
> select
Estoy tomando el sol
.
q
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Estoy tomando el sol
.
q
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
m forwarding this to Sanja.
IMHO current behaviour is absolutly correct.
Mikhail.
- Original Message -
From: "Heikki Tuuri" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 24, 2003 11:43 PM
Subject: Re: InnoDB locking: Different behavior on 3.23.55
Message -
From: ""Mikhail Entaltsev"" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.mysql
Sent: Thursday, July 24, 2003 3:44 PM
Subject: InnoDB locking: Different behavior on 3.23.55 and 4.0.13
> --=_NextPart_000_0119_01C351F2.03137C50
> Content-Typ
Hi
I have 2 MySQL servers:
Server1 is 3.23.55-max-log
Server2 is 4.0.13-standard-log
Let's assume that we have 2 connections (Conn1 and Conn2) and table test:
CREATE TABLE `test` (
`id` int(3) NOT NULL auto_increment,
`name` char(
sql,query
While working with record level locking on innodb tables we noted some
behavior that has us a bit befuddled.
The problem, in its simple form, is that I have two processes accessing the
same table. Process A does the following:
begin;
select * from table1 for update limit 5;
Now proce
- Original Message -
From: "Jeremy Zawodny" <[EMAIL PROTECTED]>
To: "Joe Shear" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, August 09, 2002 5:27 PM
Subject: Re: InnoDB Locking Problems
> On Fri, Aug 09, 2002 at 02:38:03PM -0700,
yes, we are running at serializable, which also explains the locking
problems, especially since we just upgraded from .49.
thanks
joe
On Fri, 2002-08-09 at 15:27, Jeremy Zawodny wrote:
> On Fri, Aug 09, 2002 at 02:38:03PM -0700, Joe Shear wrote:
>
> [snip]
>
> > COMMIT
> > we are using the high
On Fri, Aug 09, 2002 at 02:38:03PM -0700, Joe Shear wrote:
[snip]
> COMMIT
> we are using the highest level of transactional security -- the term for
> it eludes me at the moment.
You mean the isolation level? Are you running at SERIALIZABLE rather
than READ-COMMITTED? IF so, why? You will h
I'm using mysql 3.23.51 w/ InnoDB tables, and am running into some
locking issues which I don't believe should occur. There are 2
transactions that seem to interfere with each other. The first
transaction is an update of one table followed by a select of another
table, ie:
BEGIN
UPDATE table1 se
28 matches
Mail list logo
