ilto:shawn.l.gr...@oracle.com]
Sent: Friday, March 21, 2014 3:34 PM
To: mysql@lists.mysql.com
Subject: Re: Locking a Database (not tables) x
Hi David.
On 3/21/2014 1:42 PM, David Lerer wrote:
Frequently, we import a production dump that contains only 1 or 2 databases into one of our QA instances
that con
1, 2014 3:34 PM
To: mysql@lists.mysql.com
Subject: Re: Locking a Database (not tables) x
Hi David.
On 3/21/2014 1:42 PM, David Lerer wrote:
> Frequently, we import a production dump that contains only 1 or 2 databases
> into one of our QA instances that contains many more databases. (i.e.
Perhaps enabling read only, followed by import with super user will do what you
want.
On Mar 22, 2014, at 12:26 AM, Manuel Arostegui wrote:
> 2014-03-21 18:42 GMT+01:00 David Lerer :
>
>> Frequently, we import a production dump that contains only 1 or 2
>> databases into one of our QA inst
2014-03-21 18:42 GMT+01:00 David Lerer :
> Frequently, we import a production dump that contains only 1 or 2
> databases into one of our QA instances that contains many more databases.
> (i.e. "database" being a "schema" or a "catalogue).
> At the beginning of the import script, we first drop all
Hi David.
On 3/21/2014 1:42 PM, David Lerer wrote:
Frequently, we import a production dump that contains only 1 or 2 databases into one of our QA instances
that contains many more databases. (i.e. "database" being a "schema" or a
"catalogue).
At the beginning of the import script, we first dro
From: Wayne Leutwyler [mailto:wleut...@columbus.rr.com]
Sent: Friday, March 21, 2014 2:12 PM
To: David Lerer
Subject: Re: Locking a Database (not tables) x
You could set max_connections = 0; then kill off any remaining connections. Do
your data load and then set you max_connections back to what it was prior.
Frequently, we import a production dump that contains only 1 or 2 databases
into one of our QA instances that contains many more databases. (i.e.
"database" being a "schema" or a "catalogue).
At the beginning of the import script, we first drop all objects in the QA
database so that it will be a
Frequently, we import a production dump that contains only 1 or 2 databases
into one of our QA instances that contains many more databases. (i.e.
"database" being a "schema" or a "catalogue).
At the beginning of the import script, we first drop all objects in the QA
database so that it will be a
Hi All,
I have situation here about Innodb locking.
In transaction, We select from XYZ transaction table values and then updates
it like below
SESSION 1:
START TRANSACTION;
SELECT ID INTO vID FROM XYZ WHERE FLAG = 1 ORDER BY TIME LIMIT 1 FOR UPDATE;
UPDATE XYZ SET FLAG=0 WHERE ID = vID
|
Is dere any way to understand locking hierarchy on that table in a day so
that we came to know at that particular time who is taking lock on users
table due to which update is taking time to finish.
Usuallu it takes less than 10 ms to execute.
Slow query log :
# User@Host: user[userA
Hi,
I have a question about Metadata Locking.
The short story is that I have a magento installation.
It ran on a mysql 5.1.41 (ubuntu). It was crashing every now and then.
(when trying to insert or delete from certain tables that ware running
sone DDL statements like truncate and alter table
Hi Guys,
I got a deadlock problem, and it puzzled me days. Hope some body could help
with some explanation for the reason of deadlock, better if some extra
advises.
*
*
*DeadLock Info:*
*
*
-
-
- (1) TRANSACTION:
TRANSACTION 13D947E32, ACTIVE 0 sec, process no 10928, OS
I have a problem that I can't understand readily. I have a database that has a
couple of tables that lock for a recognizable period of time. The reason I
know is because during the lock the application stops responding totally. The
storage engine is MyIsam. I have reread everything about loc
Mon,
If I understood well, skip-locking isn't for you. IMHO, if you have a
unique process (mysqld) that manages your tables and statements are
causing deadlock, maybe you should try InnoDB. Try simulate a parallel
environment changing the storage engine and tell us. (Take a look in
the mod
Hi,
The first main difference is that InnoDB has transactional
capabilities (all-or-nothing) and MyISAM not yet. If you need to use
COMMIT on some statements, you need to use InnoDB. The second point is
the locking of MyISAM, which is on table-level. If your environment is
mixed with read/write
Any idea on this?
-Mon
From: Michael Satterwhite
To: mysql@lists.mysql.com
Sent: Mon, September 13, 2010 1:07:38 AM
Subject: Re: skip locking
Received.
On Sunday, September 12, 2010 09:32:12 am monloi perez wrote:
> Hi All,
>
> Sorry if I post
Received.
On Sunday, September 12, 2010 09:32:12 am monloi perez wrote:
> Hi All,
>
> Sorry if I posted on the wrong list.
>
> I've had this issue with my previous server already, seems like
> skip-locking configuration does not seem to work on myisam tables.
>
>
Hi All,
Sorry if I posted on the wrong list.
I've had this issue with my previous server already, seems like skip-locking
configuration does not seem to work on myisam tables.
Also what is the difference between myisam and innodb tables. The reason I
wanted to know is that I think
On Sat, Feb 6, 2010 at 12:11 PM, D. Dante Lorenso wrote:
> I have a system that imports about 40 million records every 2 days into a
> single table in MySQL. I was having problems with LOAD DATA CONCURRENT
> LOCAL INFILE where the table I was importing into would lock until the
> import was compl
I have a system that imports about 40 million records every 2 days into
a single table in MySQL. I was having problems with LOAD DATA
CONCURRENT LOCAL INFILE where the table I was importing into would lock
until the import was complete. Locks would prevent SELECTs also.
I converted the table
2009/12/23 Ryan Chan :
> Hey.
>
> Back to few years ago, InnoDB require table level locking when
> inserting auto-increment PK to the table, and Heikki said there will
> be a fix.
>
> Is this problem still exist now?
If you refer to this bug:
<http://bugs.mysql.com/bug.p
Hey.
Back to few years ago, InnoDB require table level locking when
inserting auto-increment PK to the table, and Heikki said there will
be a fix.
Is this problem still exist now?
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http
Hi everyone,
I have an application that spawns various threads for inserting into various
table. Additionally, another thread is launched to delete old records.
They all use JPA and entity managed transactions. I think I'm getting
locking issues, but I'm not sure. So, I'd l
Hi,
I'm having a strange problem with table locking. I have written a stored
procedure that only accesses a single table. Before executing the
procedure, I'm trying to lock the table in question for writing. The
LOCK TABLE command succeeds, but when I execute the stored procedure it
MySQL University: Low-Level Locking in mysqld and InnoDB
Happy New Year!
MySQL University sessions are starting again after the winter break.
This Thursday, we're beginning with Tim Cook's presentation on low-level
locking in mysqld and InnoDB – the good, the bad, and the ugly. Tim
wo
Hi David,
I think try using show full processlist that shall tell the query that is
running. I think the problem is with your query only. we need to fine tune
the query. Please send the query and the explain plan for the same. share
more stats on things that you notice during that time.
Regards
At 01:07 PM 1/7/2009, David Scott wrote:
1) InnoDb
2) 5.0.51 on Linux
3) No, a Select with a bunch of Joins, a Where, group and order
4) 37 seconds
5) Yes
6) Show Processlist does not show anything, just the user, what are you
looking for?
David,
I was looking to see if the other queries
Oh and we increased the key_buffer_size=1200M (30% of ram) no change.
2009/1/7 David Scott
> 1) InnoDb2) 5.0.51 on Linux
> 3) No, a Select with a bunch of Joins, a Where, group and order
> 4) 37 seconds
> 5) Yes
> 6) Show Processlist does not show anything, just the user, what are you
> looking
1) InnoDb2) 5.0.51 on Linux
3) No, a Select with a bunch of Joins, a Where, group and order
4) 37 seconds
5) Yes
6) Show Processlist does not show anything, just the user, what are you
looking for?
2009/1/7 mos
> At 11:20 AM 1/7/2009, you wrote:
>
>> When we run a large query other queries start
At 11:20 AM 1/7/2009, you wrote:
When we run a large query other queries start to back up when the large one
gets to the 'creating sort index' phase, this lock seems to affect the whole
server, all databases... does anyone know what may be causing this?
Thanks in advance
--
David Scott
David,
On Wed, Jan 7, 2009 at 6:20 PM, David Scott
wrote:
> When we run a large query other queries start to back up when the large one
> gets to the 'creating sort index' phase, this lock seems to affect the
> whole
> server, all databases... does anyone know what may be causing this?
>
More specifics
When we run a large query other queries start to back up when the large one
gets to the 'creating sort index' phase, this lock seems to affect the whole
server, all databases... does anyone know what may be causing this?
Thanks in advance
--
David Scott
Thanks for the improved query.The indexing didn't help much and still the
main problem is it locking all updates to the tables while it executes...
even if I am executing it on a copy of the tables in a different database
--
Dave
2008/11/27 Chandru <[EMAIL PROTECTED]>
> Hi Da
Hi David,
can you please let me know what is the select query and the update query
along with the explain plan of the same.
can you please let me know if you are using innodb storage engine?
Regards,
Chandru
www.mafiree.com
On Thu, Nov 27, 2008 at 4:45 PM, David Scott
<[EMAIL PROTECTED]>wrot
show full processlist
userX is the user the site is using to connect
databaseX is the database in question
1976156, 'userX', 'localhost', 'databaseX', 'Sleep', 13, '', ''
13508974, 'dave', 'IPX:29212', 'databaseX', 'Sleep', 0, '', ''
13759139, 'sen', '1 IPX:32775', '', 'Sleep', 160, '', ''
1377562
can u please do "show full processlist" when the update is happening, and
if its innodb
please do "SHOW INNODB STATUS", which will give complete activity on innodb
engine, including lock information.
Please show use the output of these.
regards
anandkl
On 11/27/08, David Scott <[EMAIL PROTEC
Hi list.We have 2 tables, both have a few inserts, many updates and the
occasional select.
When running a select joining the 2 tables (which can take upto 20 seconds
to complete, they are large tables) all updates are blocked and the
maxconnections is quickly reached.
We tried copying the data to
Hi,
This Thursday, Stewart Smith will give a MySQL University session:
http://forge.mysql.com/wiki/Checking_Threading_and_Locking_With_Helgrind
(topic: Checking Threading and Locking With Helgrind)
*** Note that this particular session starts 9:00 BST / 10:00 CET /
18:00 Brisbane/Melbourne
On Thu, Aug 28, 2008 at 1:14 PM, Jose Estuardo Avila <[EMAIL PROTECTED]> wrote:
> My point is that on my process lists there are no writes being done at that
> time only reads and actually only one read all other reads are locked as
> well as writes.
Sure, that's because the reads are in line behi
p and its always a select taking too long thats locking other
selects that use the same table. Writes are locked as well which I
understand but why the reads. I can provide you with all the process
list at one point you will see there are no writes being done at that
specific time. only one
get half-written garbage. Read locks are
shared, but write locks are exclusive, so they have to wait for reads
to finish.
You may find this section on locking helpful:
http://dev.mysql.com/doc/refman/5.0/en/internal-locking.html
It also links to an explanation of concurrent inserts, which is a
s
In the last episode (Aug 28), Jose Estuardo Avila said:
> On Aug 28, 2008, at 5:48 AM, "Perrin Harkins" wrote:
> > On Wed, Aug 27, 2008 at 8:21 PM, Jose Estuardo Avila wrote:
> >> Hi, I've been trying to find information on how myisam handles
> >> locks.
; wrote:
On Wed, Aug 27, 2008 at 8:21 PM, Jose Estuardo Avila
<[EMAIL PROTECTED]> wrote:
Hi, I've been trying to find information on how myisam handles
locks. I
though myisam had locking only on writes and not on reads.
No, readers block writers. This true of any system that only
On Wed, Aug 27, 2008 at 8:21 PM, Jose Estuardo Avila <[EMAIL PROTECTED]> wrote:
> Hi, I've been trying to find information on how myisam handles locks. I
> though myisam had locking only on writes and not on reads.
No, readers block writers. This true of any system that only h
Hi, I've been trying to find information on how myisam handles locks.
I though myisam had locking only on writes and not on reads. For some
reason and after a lot of digging i've been seeing that some
queries(albeit bad queries) cause other queries to hang even though
they are
Perrin Harkins wrote:
> Assuming you're using InnoDB tables, "SELECT...FOR UPDATE" will lock
> the rows as you describe. It can prevent other inserts and updates to
> neighboring rows as well, depending on what isolation level you're
> running (default is REPEATABLE READ).
Thanks, in fact it eve
On Sat, Aug 9, 2008 at 8:10 AM, John Smith <[EMAIL PROTECTED]> wrote:
> Now here's the question: I need to lock certain rows, so that no other
> client can read or write that rows (I want those clients to wait until the
> transaction is commited or rolled back). I don't want to lock the entire
> ta
Hi,
i'm currently experimenting with nested sets. To insert a new node,, I
need 1 SELECT, 2 UPDATE and 1 INSERT statement.
Of course all of this wii be packed into a transaction, because the table
could get corrupted if not all of the mentioned queries are executed.
Now here's the question: I nee
Locking will ocours with MyISAM tables when INSERT, UPDATE, DELETE or REPLACE
statemats arrive that tables, lock at the table level. In INNODB engine, a lock
ocours at the row-level.
BDB have lock at the page-level.
Wagner Bianchi
Diretor de Tecnologia - INFODBA C&T
[EMAIL PROTECTED] -
the
following case, and ideally clarify the dox too...
The question comes up in the first paragraph of 13.5.10.4. Consistent
Non-Locking Read:
http://dev.mysql.com/doc/refman/5.1/en/innodb-consistent-read.html
"A consistent read means that InnoDB uses multi-versioning to present
to a qu
On Sat, May 10, 2008 at 4:24 PM, JW <[EMAIL PROTECTED]> wrote:
>> Table locking will occur with MyISAM tables when any row(s) of the table is
>> being updated (Update,Delete,Insert,Load Data etc).
>> If you are only executing Select statements, then they can be executed in
> Table locking will occur with MyISAM tables when any row(s) of the table is
> being updated (Update,Delete,Insert,Load Data etc).
> If you are only executing Select statements, then they can be executed in
> parallel and won't be blocked.
Just curious: you say "with MyIS
n a single
core,
and if that thread locks a table, then no other threads that need that table
can execute until the locking thread/query is complete. Short answer: MySQL
works well on multi-core machines until you lock a table."
One of our programmers was wondering if this is referrin
s interesting tidbit:
***
"MySQL On Multi-Core Machines - The DevShed technical tour explains that MySQL
can spawn new threads, each of which can execute on a different
processor/core.
What it doesn’t say is that a single thread can only execute on a single core,
and if that thread
...
The question comes up in the first paragraph of 13.5.10.4. Consistent
Non-Locking Read:
http://dev.mysql.com/doc/refman/5.1/en/innodb-consistent-read.html
"A consistent read means that InnoDB uses multi-versioning to present
to a query a snapshot of the database at a point in time. The
commit;
> => I get 10 video_id
>
>
> How can I tell mysql to lock only rows that are selected and allow other
> sessions to query the table without be locking on the entire table?
It is only locking the rows it selected. Your problem is that both
queries select the s
state!!
commit;
=> I get 10 video_id
How can I tell mysql to lock only rows that are selected and allow other
sessions to query the table without be locking on the entire table?
Tks
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
partitions and
everything works without any locking issues.
I would really be thankful if someone could tell me as to "how correct
am i?"
--
Anup Shukla
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
> Sequences, if I got that right, need the new value to be stored
> immediately, i.e. outside of an active transaction. This requires a
> second connection to the database which probably causes more
> implementation work for my web application.
You mean real sequences? As with Oracle? Then no, yo
lled "SEQUENCES":
Yes, I've read it and actually put a flag on that message, but then I
decided to go for the other flagged message that explained SELECT ...
FOR UPDATE. I did some tests with multiple client windows and found that
the locking is good enough. I use it for finding new
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
nd what happens if I do an operation with CatTBL,
while FooTBL is trying to write to CatTBL because of the trigger. If CatTBL
is in use, does the trigger on FooTBL not get implemented? How does locking
CatTBL play a role in this?
My basic need is to reliably be able to ensure that everytime a
Yves,
Did you read this reply I send earlier? I think it does what you
want without needing to "lock" anything, thus making it portable.
> > >> Damn, I found out that I need table locking *and* transactions.
> > >
> > > What makes you say that?
> >
On Nov 13, 2007 3:32 PM, Yves Goergen <[EMAIL PROTECTED]> wrote:
> I found the Oracle reference and it says that locks can never lock
> queries, so reading a table is possible in any case.
No, you just have to use FOR UPDATE and it will block.
- Perrin
--
MySQL General Mailing List
For list arc
On 13.11.2007 20:43 CE(S)T, Baron Schwartz wrote:
> -- cxn 2
>
> set autocommit=0;
> begin;
> select * from t1;
> -- hangs
Delete my last message. I just did it again and now it works, too. I
have no idea what I did a couple of minutes ago, but it must have been
wrong.
Okay. Works, too. I was do
't use the "FOR UPDATE" in the second connection.
If I do (which is likely to be the case in an application because there,
the same code is run concurrently), the second SELECT locks. (The same
is true when I select MAX(id) instead of *.) If I don't, it still works.
Okay, so we
On 13.11.2007 20:43 CE(S)T, Baron Schwartz wrote:
> Yves Goergen wrote:
>> I assume that at this point, any SELECT on the table I have locked
>> should block. But guess what, it doesn't. So it doesn't really lock.
>>
>
> What kind of lock are you using?
>
> -- cxn 1
>
> set autocommit=0;
> begin
Yves Goergen wrote:
On 13.11.2007 19:19 CE(S)T, Perrin Harkins wrote:
"You can use next-key locking to implement a uniqueness check in your
application: (...)
http://dev.mysql.com/doc/refman/5.0/en/innodb-next-key-locking.html
This doesn't help my problem either. It may lock new
On 13.11.2007 19:19 CE(S)T, Perrin Harkins wrote:
> "You can use next-key locking to implement a uniqueness check in your
> application: (...)
> http://dev.mysql.com/doc/refman/5.0/en/innodb-next-key-locking.html
This doesn't help my problem either. It may lock new INSERTs t
Yves Goergen wrote:
On 13.11.2007 14:01 CE(S)T, Baron Schwartz wrote:
It's more complicated than that. You can use them together, you just
have to do it like this:
set autocommit = 0;
begin;
lock tables;
-- you are now in a transaction automatically begun by LOCK TABLES
.
I assume that
On 13.11.2007 14:01 CE(S)T, Baron Schwartz wrote:
> It's more complicated than that. You can use them together, you just
> have to do it like this:
>
> set autocommit = 0;
> begin;
> lock tables;
> -- you are now in a transaction automatically begun by LOCK TABLES
> .
I assume that at this
what you
> need.
Interesting, I didn't think that would work, but the manual does say it will:
"You can use next-key locking to implement a uniqueness check in your
application: If you read your data in share mode and do not see a
duplicate for a row you are going to insert, then you ca
Yves Goergen wrote:
(Damn I hate those lists that don't come with a Reply-To to the list!
Resending...)
On 13.11.2007 17:39 CE(S)T, Baron Schwartz wrote:
Yves Goergen wrote:
Row level locking can only lock rows that exist. Creating new rows (that
would have an influence on my MAX value
(Damn I hate those lists that don't come with a Reply-To to the list!
Resending...)
On 13.11.2007 17:39 CE(S)T, Baron Schwartz wrote:
> Yves Goergen wrote:
>> Row level locking can only lock rows that exist. Creating new rows (that
>> would have an influence on my MAX value
Yves Goergen wrote:
On 13.11.2007 16:37 CE(S)T, mark addison wrote:
As your using InnoDB, which has row level locking a SELECT ... FOR
UPDATE should work.
http://dev.mysql.com/doc/refman/4.1/en/innodb-locking-reads.html
e.g.
BEGIN TRANSACTION
new_id := (SELECT MAX(id) FROM table FOR UPDATE
On 13.11.2007 14:01 CE(S)T, Baron Schwartz wrote:
> It's more complicated than that. You can use them together, you just
> have to do it like this:
>
> set autocommit = 0;
Is this the key that I have missed? I thought that setting autocommit =
0 is pointless when I issue statements within a tra
On 13.11.2007 16:37 CE(S)T, mark addison wrote:
> As your using InnoDB, which has row level locking a SELECT ... FOR
> UPDATE should work.
> http://dev.mysql.com/doc/refman/4.1/en/innodb-locking-reads.html
> e.g.
>
> BEGIN TRANSACTION
> new_id := (SELECT MAX(id) FROM
ailure should work fine.
From what I've read about MySQL's table locks and InnoDB, you cannot
use
LOCK TABLES with transactions. Either of them deactivates the other one.
Beginning a transaction unlockes all tables, locking tables ends a
transaction.
It's more complicated than th
Yves,
> >> Damn, I found out that I need table locking *and* transactions.
> >
> > What makes you say that?
>
> BEGIN TRANSACTION
> SELECT MAX(id) FROM table
> INSERT INTO table (id) VALUES (?)
> INSERT INTO othertable (id) VALUES (?)
> COMMIT
>
> F
noDB variant of LOCK TABLES
> > has been planned that can be executed in the middle of a transaction.
I read that as saying that you can't issue a LOCK TABLES and then
another LOCK TABLES in the same transaction, because it causes a
COMMIT before locking the tables. You can use on
k fine.
From what I've read about MySQL's table locks and InnoDB, you cannot use
LOCK TABLES with transactions. Either of them deactivates the other one.
Beginning a transaction unlockes all tables, locking tables ends a
transaction.
It's more complicated than that. You can use th
ailure should work fine.
>From what I've read about MySQL's table locks and InnoDB, you cannot use
LOCK TABLES with transactions. Either of them deactivates the other one.
Beginning a transaction unlockes all tables, locking tables ends a
transaction.
>>> That Perl module us
one.
>> Beginning a transaction unlockes all tables, locking tables ends a
>> transaction.
>
> I don't think that's correct. At least that's not how I read this:
> http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html
>
> It sounds like you issue
On Nov 12, 2007 5:58 PM, Yves Goergen <[EMAIL PROTECTED]> wrote:
> BEGIN TRANSACTION
> SELECT MAX(id) FROM table
> INSERT INTO table (id) VALUES (?)
> INSERT INTO othertable (id) VALUES (?)
> COMMIT
>
> First I find a new id value, then I do several INSERTs that need to be
> atomic, and especially
On 12.11.2007 23:31 CE(S)T, Perrin Harkins wrote:
> On Nov 12, 2007 5:24 PM, Yves Goergen <[EMAIL PROTECTED]> wrote:
>> Damn, I found out that I need table locking *and* transactions.
>
> What makes you say that?
BEGIN TRANSACTION
SELECT MAX(id) FROM table
INSERT I
On Nov 12, 2007 5:24 PM, Yves Goergen <[EMAIL PROTECTED]> wrote:
> Damn, I found out that I need table locking *and* transactions.
What makes you say that?
> Maybe I'm really better off using a sequence (like the one PostgreSQL
> offers and like it is available as an add-on
On 12.11.2007 22:16 CE(S)T, Yves Goergen wrote:
> Since I only need these locks for
> a very short time and a single table with no transaction support, this
> works fine for me.
Damn, I found out that I need table locking *and* transactions. I'm lost...
Maybe I'm really
On 12.11.2007 20:43 CE(S)T, Yves Goergen wrote:
> I'll have a look at those isolation levels though. Maybe it's what I'm
> looking for.
Not quite. But I'm going the LOCK TABLES way now. Locking a single table
exclusively for those rare moments seems to be the be
On Nov 12, 2007 2:43 PM, Yves Goergen <[EMAIL PROTECTED]> wrote:
> SELECT COUNT(*) FROM table WHERE name = ?
> -- a short delay which is long enough for a concurrent request :(
> UPDATE table SET name = ? WHERE id = ?
I think that even with SERIALIZABLE isolation level, this won't lock
anything if
Okay, I feel like I need to clarify some things.
I do have a UNIQUE INDEX constraint on those columns, so the other user
won't actually write the same value another time, but it will fail at a
level which it should not.
I don't want to use AUTO_INCREMENT because it's not portable. My
application
On Nov 12, 2007 1:25 PM, Yves Goergen <[EMAIL PROTECTED]> wrote:
> When I start a transaction, then find the maximum value of a column and
> use that + 1 to write a new row into the table, how do transactions
> protect me from somebody else doing the same thing so that we'd both end
> up writing a
Hello Yves,
> there's very much information about how transactions and locking works
> in InnoDB, but maybe there's also a simple and understandable answer to
> my simple question:
>
> When I start a transaction, then find the maximum value of a column and
> use that
Hi,
there's very much information about how transactions and locking works
in InnoDB, but maybe there's also a simple and understandable answer to
my simple question:
When I start a transaction, then find the maximum value of a column and
use that + 1 to write a new row into the tab
-
From: "Baron Schwartz" <[EMAIL PROTECTED]>
To: "Justin" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, September 03, 2007 4:42 PM
Subject: Re: servers full potential / FT searches locking tables
Justin wrote:
lockup just happened again.. here's a innodb stat
Justin wrote:
lockup just happened again.. here's a innodb status.
InnoDB status will be basically useless, as full-text is only applicable
to MyISAM, and indeed your status output shows only one transaction is
running (the one running 'show innodb status') and InnoDB has done zero
work sinc
iday, August 31, 2007 4:28 PM
Subject: Re: servers full potential / FT searches locking tables
Alright.. I think I see what's is happening after this latest lockup..
here's what I think is happening..
When a replace into query locks a table for a few seconds there are a boot
load
- Original Message -
From: "Michael Dykman" <[EMAIL PROTECTED]>
To: "Justin" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, August 28, 2007 1:31 PM
Subject: Re: servers full potential / FT searches locking tables
No, I'm afraid not. 32 bit architectures have
Sorry man, as everyone keeps saying, there is only 4 gig of ram in the
entire known 32 bit universe.. that includes space for
process-specific system buffers, file handles, internals... the
TOTAL amount of ram you can give to 32-bit MySQL in ANY combination is
around 3.5G (many will tell you, not
On Wed, 29 Aug 2007 18:02:31 -0400, "Michael Dykman" <[EMAIL PROTECTED]>
said:
> I mean that the theoretical limit of a 32-bit application is 4G... in
> practice, you won't quite get that (for a pile of practical reasons)..
> best to keep your configured memory requirements to around 3.5G or
> y
I mean that the theoretical limit of a 32-bit application is 4G... in
practice, you won't quite get that (for a pile of practical reasons)..
best to keep your configured memory requirements to around 3.5G or
you will run into weird errors.
- michael dykman
On 8/28/07, Ken Peng <[EMAIL PROTECTE
1 - 100 of 581 matches
Mail list logo
