uctures involved in your
> query around the
> rows that have been returned bt a SELECT ... FOR UPDATE. As your selects return
> nothing, InnoDB
> doesn't find any index sections to place any locks on.
>
> Perhaps you should look at using the SERIALIZABLE level of transacti
1024
>
> Field Start Length Nullpos Nullbit Type
> 1 1 1
> 2 2 4
> 3 6 2
> 4 8 4
> 5 122
> 6 141
> 7 154
>
>
> Dr. Gregory B. Newby, Research Faculty, Arctic Region Supercomputing Center
> University of Alaska Fairbanks. PO Box 756020, Fairbanks, AK 99775
> e: newby AT arsc.edu v: 907-474-7160 f: 907-474-5494 w: www.arsc.edu/~newby
--
Joe Shear <[EMAIL PROTECTED]>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
>
> Best regards,
>
> Heikki Tuuri
> Innobase Oy
> http://www.innodb.com
> Foreign keys, transactions, and row level locking for MySQL
> InnoDB Hot Backup - a hot backup tool for MySQL
>
> Order MySQL technical support from https://order.mysql.com/
>
> - Origi
ctive
transactions.
--
Joe Shear <[EMAIL PROTECTED]>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
ROLL BACK TRANSACTION (2)
--
Joe Shear <[EMAIL PROTECTED]>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
, then there is a leak
> in InnoDB.
>
> MySQL-4.0.14 has better diagnostic prints. It would be easier to find the
> problem with it.
>
> Regards,
>
> Heikki
>
> - Original Message -
> From: "Joe Shear" <[EMAIL PROTECTED]>
> To: &q
find the lowest cost
> solution, with decent reliability.
>
> And I'm trying to find the secret of eternal youth :)
>
We're considering moving to a solution like EMC's -- do you or anybody
else have any experience with that?
> Cheers,
>
> Andrew
>
&g
you have UPS so that if the power fails
> you can get a clean shutdown. And ignore backups completely.
>
> Hope this helps,
>
> Andrew
>
>
>
> -Original Message-
> From: Joe Shear [mailto:[EMAIL PROTECTED]
> Sent: Wednesday 23 July 2003 21:50
> To: Andrew Braithwaite
p is
> being performed?
>
> Let me know and I think I'll be able to help :)
>
> Cheers,
>
> Andrew
>
>
> -Original Message-
> From: Joe Shear [mailto:[EMAIL PROTECTED]
> Sent: Wednesday 23 July 2003 21:08
> To: [EMAIL PROTECTED]
> Subj
On Wed, 2003-07-23 at 13:11, Heikki Tuuri wrote:
> Joe,
>
> - Original Message -
> From: "Joe Shear" <[EMAIL PROTECTED]>
> To: "Heikki Tuuri" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, J
ike this? What kind of backup solutions did
you use? We aren't too concerned about the CPU usage as our databases
tend to be i/o bound.
--
Joe Shear <[EMAIL PROTECTED]>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Wed, 2003-07-23 at 12:56, Heikki Tuuri wrote:
> Joe,
>
> - Original Message -
> From: "Joe Shear" <[EMAIL PROTECTED]>
> Newsgroups: mailing.database.mysql
> Sent: Wednesday, July 23, 2003 10:40 PM
> Subject: RE: mysql stops processing
>
>
> >
ctions
> on the DB. To find out if this is the case, when your server gets into this
> state run a "mysqladmin -v pro" and see if all the queries are waiting for a
> lock to be freed up.
>
> Hope this helps,
>
> Andrew
>
> -Original Message-
> From:
Hi,
Has anyone ever had any problems with MySQL w/ all InnoDB tables just
stop processing queries? There doesn't seem to be any pattern to it, it
happens at times of relatively high load (load avg of 4 on a dual proc)
but the CPUs still have plenty of idle time, and the disks aren't maxing
out.
www.mysql.com/doc/C/r/Crashing.html
contains
information that should help you find out what is causing the
crash
--
Joe Shear <[EMAIL PROTECTED]>
-
Before posting, please check:
http://www.mysql.c
Hi,
I'm running mysql 3.23.52 w/ innodb tables, and I started getting some
deadlocks since upgrading from .51. When I do a show innodb status in
prints out the following:
020826 19:22:15 LATEST DETECTED DEADLOCK:
*** (1) TRANSACTION:
TRANSACTION 0 16655549, ACTIVE 1 sec, OS thread id 87339022 i
A better solution would probably be to implement a form of challenge
response authentication. (IE: Personal Question/Answer). This way, the
attacker has to know the challenge response to even begin the password
change transaction. Additionally, it is a security hole to email anyone
their passwo
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
&g
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
It depends on your needs. ENCRYPT, MD5, SHA1 are all hash functions,
which means they are one-way and the SSN can't be recovered. This means
that you can't read their SSN back once they give it to you, you can
only compare something they give you and see if it is the same as the
SSN. This is ho
Hi,
I have a mysql database with innodb tables, and I keep running into a
deadlock that is not detected (causes a timeout) and that I don't think
should be happening. Can anyone explain why this is causing a deadlock,
and secondly, how can I fix it or how can I change this so that the
deadlock wi
21 matches
Mail list logo