Hi Heikki,
Yes indeed. We have a "uid" field that is AUTO INC. Is the error more
an issue of the auto inc code in InnoDB not setting its error codes
correctly on a rollback than the auto increment code initiating an
error? Thank you in advance.
Best Regards,
Jason
On 12/31/06, Heikki Tuuri <[EM
Jason,
I am Cc:ing the MySQL General mailing list, so that others who bump into
this bug can find this discussion.
Jason J. W. Williams wrote:
Mr. Tuuri,
We have a high degree of UPDATE/INSERT concurrency along with high
SELECTs. It causes a deadlock about once every 24 hours. In this case
a
Hello,
I noticed the error messages below in my MySQL error log and found
them a bit perplexing. Can't find anything on them in the MySQL
documentation. If anyone has any clue what they mean it is greatly
appreciated. As a sidenote, SHOW INNODB STATUS completes, but only
shows through the DEADLOC
Stuart,
ok, then this is a complete mystery. I have not heard about this before.
Regards,
Heikki
- Original Message -
From: "Stuart Felenstein" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Monday, November 29, 2004 9:33 PM
Subject: Re: Bizarre t
--- Heikki Tuuri <[EMAIL PROTECTED]> wrote:
> Stuart,
>
> you probably have
>
> skip-innodb
>
> in my.cnf.
>
> Best regards,
>
> Heikki Tuuri
Heikki - Nope , doesn't seem so. My.cnf is below.
Also, I'm guessing that if it was set to skip-innodb,
I wouldn't not have had the ability to chang
-
From: "Stuart Felenstein" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Monday, November 29, 2004 9:58 AM
Subject: Re: Bizarre table type switch
--- Stuart Felenstein <[EMAIL PROTECTED]> wrote:
I'm not sure what happened but when I ran some test
yesterday o
Hello.
Usually you should follow instructions in chapters at:
http://dev.mysql.com/doc/mysql/en/Debugging_server.html
Stuart Felenstein <[EMAIL PROTECTED]> wrote:
> I'm not sure what happened but when I ran some test
> yesterday on a "transaction" it failed. Being puzzled
> I started
--- Stuart Felenstein <[EMAIL PROTECTED]> wrote:
> I'm not sure what happened but when I ran some test
> yesterday on a "transaction" it failed. Being
> puzzled
> I started digging around. I have come to find out
> that all the tables involved were now set to MyISAM.
>
> Obviously transactions
I'm not sure what happened but when I ran some test
yesterday on a "transaction" it failed. Being puzzled
I started digging around. I have come to find out
that all the tables involved were now set to MyISAM.
Obviously transactions wouldn't work.
The odd thing that I'd like to figure out is ho
Sorry for the long reply:
At 02:57 PM 6/10/2002 -0500, you wrote:
>[snip]
>SELECT
> head.po
>FROM
> head
> LEFT JOIN line ON (head.sn=line.snHead)
>WHERE
> head.po > 1
> AND line.dateETA<='2002-06-10'
>LIMIT 50
>
>As is, this query is very fast (0.01 second
[snip]
SELECT
head.po
FROM
head
LEFT JOIN line ON (head.sn=line.snHead)
WHERE
head.po > 1
AND line.dateETA<='2002-06-10'
LIMIT 50
As is, this query is very fast (0.01 seconds when there are 25,000 records
in 'head', and 50,000 records in 'line'). However,
Hi List,
I sure do appreciate this list.
I'm stumped on the following query:
SELECT
head.po
FROM
head
LEFT JOIN line ON (head.sn=line.snHead)
WHERE
head.po > 1
AND line.dateETA<='2002-06-10'
LIMIT 50
As is, this query is very fast (0.01 seconds when the
On Fri, 5 Oct 2001, Dan Nelson wrote:
> This rules out mysql as the cause for the delay.
I agree.
> > > I'd say start dumping packets on the network.
> >
> > I'd agree, but I'm confused as to why a different query (that
> > requests more data; 33 rows vs 1) can reliably execute and fetch in
> >
In the last episode (Oct 05), Philip Brown said:
> > What are your timings if you run your client on the SCO box? mysql
> simply reports a query time of 10ms or less (0.01s). Of course, this
> doesn't have any network overhead.
This rules out mysql as the cause for the delay.
> > I'd say star
On Fri, 5 Oct 2001, Philip Brown wrote:
> > How is your DNS, WINS,... setup? SCO/Caldera UNIX can use DNS when you do
> > not think it will. Most SCO/Caldera tcp what ever will do a forward and
> > reverse DNS look-up. I can add entries in the MS machines in the hosts
> > file location MS OS/in
as on the first.
It is bizarre how the query that asks for 33 rows on an indexed field
works fine, yet the query that asks for 1 row on the primary key performs
so badly.
> What are your timings if you run your client on the SCO box?
mysql simply reports a query time of 10ms or less (0.01s). Of
>
> - Original Message -
> From: "Philip Brown" <[EMAIL PROTECTED]>
> To: "Russell Miller" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Friday, October 05, 2001 1:34 PM
> Subject: RE: Bizarre query performance
>
>
> >
> How is your DNS, WINS,... setup? SCO/Caldera UNIX can use DNS when you do
> not think it will. Most SCO/Caldera tcp what ever will do a forward and
> reverse DNS look-up. I can add entries in the MS machines in the hosts
> file location MS OS/install dependent and very times.
All machines ha
here are 2 times I am interested in, the time to execute a query, and the
> time required to fetch the results across the network (100Mbps LAN, 3
> isolated workstations in test setup).
>
> Basically I have been timing the mysql_query() and the mysql_store_result()
> calls on the client. I
OTECTED]>
Sent: Friday, October 05, 2001 1:34 PM
Subject: RE: Bizarre query performance
> > Have you tried "explain"ing the two select to see where all the time is
> > being spent and how the queries a
On Fri, 5 Oct 2001, Philip Brown wrote:
> Environment:
>
> Server: SCO OpenServer V3.2 R5.0.5, AMD K6-2 350Mhz CPU, 128Mb RAM
> mySQL: 3.23.39, compiled by me to avoid use of libraries, using latest
> available pthreads
... much deleted...
> Can anyone give me some assistance
> Have you tried "explain"ing the two select to see where all the time is
> being spent and how the queries are optimized?
Sorry, I should have included that in my detail.
+---+---+---+-+-+---+--+---+
| table | type | possible_keys | key | key
Have you tried "explain"ing the two select to see where all the time is
being spent and how the queries are optimized?
--Russell
- Original Message -
From: "Philip Brown" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 05, 200
the network (100Mbps LAN, 3
isolated workstations in test setup).
Basically I have been timing the mysql_query() and the mysql_store_result()
calls on the client. I have been getting some very bizarre results, that are
100% reproducible:
QUERY 1: SELECT * FROM X WHERE ID=100
ID is defined as the
m the necessary 'refresh' (which occures when you do a "flush
>privileges"), but was 'triggered' when you changed the users' password
>
>
>Turtle wrote:
>
>> Ok.. even more bizarre... IN addition to what I told you in my last posting,
>>
Perhaps the 'replication' of 'user' data (and/or other MySQL 'control' data)
doesn't perform the necessary 'refresh' (which occures when you do a "flush
privileges"), but was 'triggered' when you changed the users' password.
Ok.. even more bizarre... IN addition to what I told you in my last posting,
I just logged onto the slave server and changed the user's password to what
it was already, and now the user can log in.
I verified the ENCRYPTED password string before and after the change, and it
was IDENTICAL!!
27 matches
Mail list logo
