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
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
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
> I suppose your test program connects, and loops the same query multiple
> times in the same session? (Just to rule out connect/disconnect
> overhead)
Of course. I also run the same query multiple times, to eliminate caching
issues. Performance on successive iterations is the same as on the fir
>
> - 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
In the last episode (Oct 05), Philip Brown said:
> 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
>
> Clients: Win32 machines (more detail later).
>
> There are 2 times I am interest
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 with this bizarre b
> 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, 2001 1:18 PM
Subject: Bizarre query performance
Aah!! Thanks :-)
I didn't know a "flush privileges;" SQL statement was necessary. I'll be sure
to remember that!
Thanks!
Brian
>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
>privile
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
Turtle wrote:
> Ok.. even more bizarre... IN addition to what I to
20 matches
Mail list logo
