Re: Query optimizer-miss with unqualified expressions, bug or feature?

- Original Message - > From: "Shawn Green" > Subject: Re: Query optimizer-miss with unqualified expressions, bug or > feature? > > On a more serious note, indexes with limited cardinality are less useful > than those with excellent cardinality. Cardinali

Re: Query optimizer-miss with unqualified expressions, bug or feature?

Hi Shawn, On 19.10.15 22.33, shawn l.green wrote: On 10/19/2015 3:48 PM, Roy Lyseng wrote: Hi Ben, On 19.10.15 16.07, Ben Clewett wrote: Hi Roy, Thanks for the clear explanation. I guess (hypothetically) the optimizer could see if it has a key, and then use two starts: one on 'a > 0' and

Re: Query optimizer-miss with unqualified expressions, bug or feature?

On 10/19/2015 3:48 PM, Roy Lyseng wrote: Hi Ben, On 19.10.15 16.07, Ben Clewett wrote: Hi Roy, Thanks for the clear explanation. I guess (hypothetically) the optimizer could see if it has a key, and then use two starts: one on 'a > 0' and one on 'a < 0', taking a union of the result? Which

Re: Query optimizer-miss with unqualified expressions, bug or feature?

a (a) ) ENGINE=InnoDB; This will hit key 'a': SELECT * FROM t WHERE a = TRUE; This will return the same results, but not use key 'a': SELECT * FROM t WHERE a; Is this a bug, or deliberate behaviour, or a missing feature, or perhaps something else? MySQL does not have a true

Re: Query optimizer-miss with unqualified expressions, bug or feature?

KEY a (a) ) ENGINE=InnoDB; This will hit key 'a': SELECT * FROM t WHERE a = TRUE; This will return the same results, but not use key 'a': SELECT * FROM t WHERE a; Is this a bug, or deliberate behaviour, or a missing feature, or perhaps something else? MySQL does not

Re: Query optimizer-miss with unqualified expressions, bug or feature?

will hit key 'a': SELECT * FROM t WHERE a = TRUE; This will return the same results, but not use key 'a': SELECT * FROM t WHERE a; Is this a bug, or deliberate behaviour, or a missing feature, or perhaps something else? MySQL does not have a true boolean type, so this is act

Query optimizer-miss with unqualified expressions, bug or feature?

E a = TRUE; This will return the same results, but not use key 'a': SELECT * FROM t WHERE a; Is this a bug, or deliberate behaviour, or a missing feature, or perhaps something else? Thanks, Ben Clewett. -- MySQL General Mailing List For list archives: http://lists.mysql.com/

Possible bug with event and delete...limit ?

kill them. I noticed, however, that the LIMIT statement I specified in the event wasn't present in the actual queries... Could that be a parser bug, or does the limit simply not show up in the process lists? Has anyone seen this before ? This is 5.5.30-1.1-log on Debian 64-bit. Tha

bzr bug or corrupted 5.7 tree?

ut on a local 5.7 branch is equally wrong ... question is whether this is a corrupted tree or actually a bzr bug ... -- Hartmut Holzgraefe, Principal Support Engineer (EMEA) SkySQL - The MariaDB Company | http://www.skysql.com/ -- MySQL General Mailing List For list archives: http://lists.mysq

link-bug

2014/01/29 16:16 -0800, neubyr https://dev.mysql.com/doc/refman/5.0/en/replication-features-load.html - Someone was not all awake when making this webpage up: four of the links under "Table of Contents" point to this same page. (I was looking because I was thinking about Neubyr

Re: severe build bug 5.5 viossl

L_OP_NO_COMPRESSION' >> undeclared (first use in this >> function) >> /tmp/mysql-5.5.32/vio/viossl.c:175: error: (Each undeclared identifier >> is reported only once >> /tmp/mysql-5.5.32/vio/viossl.c:175: error: for each function it appears >> in.) >

Re: severe build bug 5.5 viossl

dir/viossl.c.o] Error 1 > make[1]: *** [vio/CMakeFiles/vio.dir/all] Error 2 > > > Question, does anyone at oracle even bother with bug tracking now days? > How can something that causes a fail of building with versions of > openssl less then 1.0.0 > go un fixed for so long. > &

severe build bug 5.5 viossl

o/CMakeFiles/vio.dir/all] Error 2 Question, does anyone at oracle even bother with bug tracking now days? How can something that causes a fail of building with versions of openssl less then 1.0.0 go un fixed for so long. Is this more proof that oracle DGAF about mysql? should I move to mariadb? b

RE: Bug in BETWEEN same DATETIME

t; Sent: Friday, May 24, 2013 11:08 AM > To: mysql@lists.mysql.com > Subject: Re: Bug in BETWEEN same DATETIME > > >>>> 2013/05/24 09:49 -0400, shawn green >>>> > Or we could coerce datetime values back to their date values when both > are being used. The

Re: Bug in BETWEEN same DATETIME

2013/05/24 09:49 -0400, shawn green Or we could coerce datetime values back to their date values when both are being used. The trick now becomes choosing between rounding the datetime value (times past noon round to the next date) or do we use the floor() function all the time. <<<

Re: Bug in BETWEEN same DATETIME

ptimized based on which part(s) are columns and which are literals. '2013-05-14 17:00:00' >= '2013-01-01' AND '2013-05-14 17:00:00' <= '2013-05-14' + INTERVAL 12 HOUR There's an extra second in that! (I call it the "mid

RE: Bug in BETWEEN same DATETIME

013-05-14 17:00:00' >= '2013-01-01' > AND '2013-05-14 17:00:00' <= '2013-05-14' + INTERVAL 12 HOUR There's an extra second in that! (I call it the "midnight bug".) I perceive (rightly or wrongly) that comparing a TIMESTAMP to someth

Re: Bug in BETWEEN same DATETIME

Hello Rick, On 5/23/2013 7:08 PM, Rick James wrote: Watch out for CAST(), DATE(), and any other function. In a WHERE clause, if you hide an indexed column inside a function, the index cannot be used for optimization. INDEX(datetime_col) ... WHERE DATE(datetime_col) = '2013-01-01' wi

Re: Bug in BETWEEN same DATETIME

Personally I don't share your view that it's a bug. Omitting the time results in midnight by default so this screws between because there's no time between 00:00:00 and 00:00:00. Are you having operational issues here or are you simply fishing for bugs? WHERE `transaction_date`

RE: Bug in BETWEEN same DATETIME

m] Sent: Thursday, May 23, 2013 3:56 PM To: mysql@lists.mysql.com Subject: Bug in BETWEEN same DATETIME I just noticed what I consider to be a bug; and related, has this been fixed in later versions of MySQL? We are using: mysql Ver 14.12 Distrib 5.0.92, for portbld-freebsd8.1 (amd64) using 5.

Re: Bug in BETWEEN same DATETIME

> That works on my test case > > You could also change the where clause to be >= date and < date+1 > > > > -Original Message- > From: Daevid Vincent [mailto:dae...@daevid.com] > Sent: Thursday, May 23, 2013 3:56 PM > To: mysql@lists.mysql.com > Subject

Re: Bug in BETWEEN same DATETIME

On 5/23/2013 4:55 PM, Daevid Vincent wrote: I just noticed what I consider to be a bug; and related, has this been fixed in later versions of MySQL? We are using: mysql Ver 14.12 Distrib 5.0.92, for portbld-freebsd8.1 (amd64) using 5.2 If you use BETWEEN and the same date for both parts

RE: Bug in BETWEEN same DATETIME

iginal Message- > From: shawn green [mailto:shawn.l.gr...@oracle.com] > Sent: Thursday, May 23, 2013 3:50 PM > To: mysql@lists.mysql.com > Subject: Re: Bug in BETWEEN same DATETIME > > > > On 5/23/2013 4:55 PM, Daevid Vincent wrote: > > I just noticed what I

RE: Bug in BETWEEN same DATETIME

he same starting date. > -Original Message- > From: Michael Dykman [mailto:mdyk...@gmail.com] > Sent: Thursday, May 23, 2013 2:56 PM > To: MySql > Subject: Re: Bug in BETWEEN same DATETIME > > >> where cast(transaction_date as date) BETWEEN '2013-04-16&#x

Re: Bug in BETWEEN same DATETIME

Sorry, that was meant to be; WHERE (new column stored as date) = '2013-04-16' On Thu, May 23, 2013 at 10:16 PM, Andrew Moore wrote: > Personally I don't share your view that it's a bug. Omitting the time > results in midnight by default so this screws between because

RE: date-IFNULL-sum bug?

2012/10/08 14:52 -0700, Rick James Do not use + for DATE arithmetic! Use, for example + INTERVAL 1 YEAR No, those operations are well defined. Amongst the timestamp-functions there is constant reference to numeric context, and character context--and well there is, because the

RE: date-IFNULL-sum bug?

Do not use + for DATE arithmetic! Use, for example + INTERVAL 1 YEAR > -Original Message- > From: h...@tbbs.net [mailto:h...@tbbs.net] > Sent: Thursday, October 04, 2012 9:35 PM > To: mysql@lists.mysql.com > Subject: date-IFNULL-sum bug? > > Can anyone explain th

date-IFNULL-sum bug?

Can anyone explain this to me? The first one seems quite wrong; the rest make perfect sense. mysql> select ifnull(date('1900/5/3'), date('1900/01/01')) + 1; +--+ | ifnull(date('1900/5/3'), date('1900/01/01')) + 1 | +--

MySQL Community Server 5.6.3 has been released (part 2 - bug fixes)

Dear MySQL users, This is the list of bug fixes. For the functional enhancements, see part 1 of this mail: Bugs fixed: * Incompatible Change: For socket I/O, an optimization for the case when the server used alarms for timeouts could cause a slowdown when socket timeouts were used

Re: a lesson in query writing and (maybe) a bug report

Hi, On 28-8-2011 4:08, shawn wilson wrote: On Sat, Aug 27, 2011 at 17:33, Arthur Fuller wrote: I agree 110%. It is completely pointless to index a column with that amount of NULLs. In practical fact I would go further: what is the point of a NULLable column? A NULL 'value' is special in most

Re: a lesson in query writing and (maybe) a bug report

On Sat, Aug 27, 2011 at 17:33, Arthur Fuller wrote: > I agree 110%. It is completely pointless to index a column with that amount > of NULLs. In practical fact I would go further: what is the point of a > NULLable column? I try to design my tables such that every column is NOT > NULL. In practice

Re: a lesson in query writing and (maybe) a bug report

It is a general rule that indexes for columns with low cardinality are not worth it, often making queries more expensive than they would be without said index. binary columns all suffer from this. - michael dykman On Sat, Aug 27, 2011 at 4:52 PM, Dave Dyer wrote: > > The "innocuous change" w

Re: a lesson in query writing and (maybe) a bug report

I agree 110%. It is completely pointless to index a column with that amount of NULLs. In practical fact I would go further: what is the point of a NULLable column? I try to design my tables such that every column is NOT NULL. In practice this is not realistic, but I try to adhere to this principle

Re: a lesson in query writing and (maybe) a bug report

Hi, On 27-8-2011 22:52, Dave Dyer wrote: The "innocuous change" was to add an index for "is_robot" which is true for 6 out of 20,000 records and null for the rest. Not useful to add an index for that. I also wonder why the value is null (meaning: unknown, not certain) for almost all records.

a lesson in query writing and (maybe) a bug report

The "innocuous change" was to add an index for "is_robot" which is true for 6 out of 20,000 records and null for the rest. My complaint/question/observation is not how to optimize the query that went awry, but to be alarmed that a venerable and perfectly serviceable query, written years ago and

Re: a lesson in query writing and (maybe) a bug report

Hi, On 27-8-2011 1:28, Dave Dyer wrote: Can you post the EXPLAIN EXTENDED output for your before and after queries? also, have you recently run an ANALYZE TABLE on the tables? What was the result of ANALYZE TABLE? What is the engine of the tables involved? // before Used keys: p2.NULL,

a lesson in query writing and (maybe) a bug report

BTW, the query on the database with the added index doesn't take forever, it takes a mere 51 minutes (vs. instantaneous). -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org

a lesson in query writing and (maybe) a bug report

BTW, the query on the database with the added index doesn't take forever, it takes a mere 51 minutes (vs. instantaneous). -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org

Re: Re: a lesson in query writing and (maybe) a bug report

> > >Can you post the EXPLAIN EXTENDED output for your before and after queries? >also, have you recently run an ANALYZE TABLE on the tables? // before mysql> explain extended select p1.player_name,g.score1,g.time1,g.color1,p2.player_name,g.score2,g.time2,g.color2,g.gamename,gmtdate -> f

Re: a lesson in query writing and (maybe) a bug report

In the last episode (Aug 26), Dave Dyer said: > This is a cautionary tale - adding indexes is not always helpful or > harmless. I recently added an index to the "players" table to optimize a > common query, and as a consequence this other query flipped from innocuous > to something that takes infi

a lesson in query writing and (maybe) a bug report

This is a cautionary tale - adding indexes is not always helpful or harmless. I recently added an index to the "players" table to optimize a common query, and as a consequence this other query flipped from innocuous to something that takes infinite time. select p1.player_name,g.score1,g.tim

Re: Query bug

ot;) Veln - Original Message - From: "Johnny Withers" To: "Velen Vydelingum" Cc: Sent: Sunday, July 24, 2011 17:41 Subject: Re: Query bug What's your vb code for outputting the results look like? On Jul 24, 2011 8:22 AM, "Velen Vydelingum"

Re: Query bug

What's your vb code for outputting the results look like? On Jul 24, 2011 8:22 AM, "Velen Vydelingum" wrote: Hi, I have the following query which is fine when I run it from the mysql shell screen: select supplier_code,0,0,0,0,0-sum(amountpaid),0 from custpayments where paymentdate<='2010-12-0

Query bug

Hi, I have the following query which is fine when I run it from the mysql shell screen: select supplier_code,0,0,0,0,0-sum(amountpaid),0 from custpayments where paymentdate<='2010-12-02' and grnno not in (Select sale_id from saletrans_cons where paymode='Credit') group by supplier_code but w

Re: Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

Sveta Smirnova at Mysql just confirmed this bug in 5.5.13: http://bugs.mysql.com/45670 On Wed, Jun 15, 2011 at 5:38 PM, Claudio Nanni wrote: > No worries! > > I think I would have figured that out! > > I'll feedback you tomorrow. > > Thanks again > > Claud

Re: Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

quot;replicate-wild-ignore-table" option in my.cnf produces > the > >> same results. > >> > >> 2. If the my.cnf "replicate-ignore-table=db.log" setting on the master > >> is > >> removed and mysql restarted so "db.log" i

Re: Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

gt; 1. Using the "replicate-wild-ignore-table" option in my.cnf produces the >> same results. >> >> 2. If the my.cnf "replicate-ignore-table=db.log" setting on the master >> is >> removed and mysql restarted so "db.log" is no lon

Re: Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

produces the > same results. > > 2. If the my.cnf "replicate-ignore-table=db.log" setting on the master is > removed and mysql restarted so "db.log" is no longer ignored in > replication, > this bug goes away and correct results are reported on the slave. &g

Re: Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

Two additional notes: 1. Using the "replicate-wild-ignore-table" option in my.cnf produces the same results. 2. If the my.cnf "replicate-ignore-table=db.log" setting on the master is removed and mysql restarted so "db.log" is no longer ignored in replication,

Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

This is a follow-up to my previous post. I have been narrowing down what is causing this bug. It is a timing issue of a replication ignored table with an auto-increment primary key values leaking over into a non-ignored table with inserts immediately after the ignore table has had rows inserted

Re: Found a possible replication bug in 5.5.8/5.5.11 (auto-increment in primary key)

Very interesting. Waiting for update. On Jun 15, 2011 4:51 AM, "Hank" wrote: > > The slave is receiving "null" as the statement based insert, not an out of > range number from the master. > > I've been doing more research all day on this bug and have a bit

Re: Found a possible replication bug in 5.5.8/5.5.11 (auto-increment in primary key)

The slave is receiving "null" as the statement based insert, not an out of range number from the master. I've been doing more research all day on this bug and have a bit more information as to what's causing it. I plan to write it up tomorrow and post it. Basically, everyt

Re: Found a possible replication bug in 5.5.8/5.5.11 (auto-increment in primary key)

>>>> 2011/06/13 22:38 -0400, Hank >>>> But that bug report was closed two years ago. I have no idea if it's the server sending bad data or the slaves. I think it's the slaves, because on the slave error, it clearly is getting this statement: "insert into

Re: Found a possible replication bug in 5.5.8/5.5.11 (auto-increment in primary key)

That is the slave relay log dump I posted (and mis-labeled). Thanks. -Hank On Tue, Jun 14, 2011 at 2:34 AM, Claudio Nanni wrote: > You should also have a look at the slave relay log. > > But in any case sounds like a bug. > > Claudio > On Jun 14, 2011 5:18 AM, "Hank"

Re: Found a possible replication bug in 5.5.8/5.5.11 (auto-increment in primary key)

You should also have a look at the slave relay log. But in any case sounds like a bug. Claudio On Jun 14, 2011 5:18 AM, "Hank" wrote: > Both my master and slave bin logs look OK (I think).. > > master bin log: > > /*!40019 SET @@session.max_insert_delayed_th

Re: Found a possible replication bug in 5.5.8/5.5.11 (auto-increment in primary key)

asic out-of-the box mysql replication. > > This appears to be an instance of this bug: > http://bugs.mysql.com/bug.php?id=45670 > > But that bug report was closed two years ago. I have no idea if it's the > server sending bad data or the slaves. I think it's the s

Re: Found a possible replication bug in 5.5.8/5.5.11 (auto-increment in primary key)

Yes, it's basic out-of-the box mysql replication. This appears to be an instance of this bug: http://bugs.mysql.com/bug.php?id=45670 But that bug report was closed two years ago. I have no idea if it's the server sending bad data or the slaves. I think it's the slaves, becau

Re: Found a possible replication bug in 5.5.8/5.5.11 (auto-increment in primary key)

Hank, I can't reproduce it right now, But it really seems a bug. Just a shot in the dark, Are you sure you have statement based and not mixed replication? I don't even know if that would affect , just an idea. Claudio On Jun 14, 2011 3:07 AM, "Hank" wrote: > Hello

Found a possible replication bug in 5.5.8/5.5.11 (auto-increment in primary key)

Hello All, I have a 64bit, 5.5.8 master, and this bug appears on both 5.5.11 and 5.5.8 32 and 64-bit slaves (statement based replication). I'm finding an auto-increment field (part of a compound primary key) updates correctly using "null" to insert the next value on the master.

Re: Bug using 32-bit libmysqlclient on a 64-bit system?

Am 13.06.2011 18:45, schrieb Alex Gaynor: > Unfortunately the decision to run 32-bit libs on 64-bit systems is outside > of my control. Given that it *should* work I'm more interested in > diagnosing whether this is a bug of some sort in libmysqlclient or a bug in > my cod

Re: Bug using 32-bit libmysqlclient on a 64-bit system?

Unfortunately the decision to run 32-bit libs on 64-bit systems is outside of my control. Given that it *should* work I'm more interested in diagnosing whether this is a bug of some sort in libmysqlclient or a bug in my code/build procedure. Alex On Sat, Jun 4, 2011 at 10:06 AM, walter

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

On Mon, 06 Jun 2011 18:54 +0200, "Johan De Meersman" wrote: > > Excluding 'performance_schema' appears to eliminate the error. And it > > seems does NOT cause a reliability-of-the-backup problem. > > Hah, no, backing that up is utterly pointless. that's a useful/final confirmation. thx. > No,

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

- Original Message - > From: ag...@airpost.net > > Excluding 'performance_schema' appears to eliminate the error. And it > seems does NOT cause a reliability-of-the-backup problem. Hah, no, backing that up is utterly pointless. Never noticed it doing that. It's basically a virtual schem

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

On Mon, 06 Jun 2011 12:44 +0200, "Johan De Meersman" wrote: > > I haven't bothered to look for the "bug", but it seems to me to be quite > reasonable default behaviour to lock the whole lot when you're dumping > transactional tables - it ensures you

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

I haven't bothered to look for the "bug", but it seems to me to be quite reasonable default behaviour to lock the whole lot when you're dumping transactional tables - it ensures you dump all tables from the same consistent view. I would rather take this up with the ZR

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

Am 05.06.2011 23:55, schrieb ag...@airpost.net: > i still have no idea why this is necessary. take it or not it is a professional solution which works for databses with 20 GB every day here with rsync without interrupt/lock mysqld a second and it is much faster > there seems to be a but, prob

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

i still have no idea why this is necessary. there seems to be a but, problem, misconfiguration, etc. wouldn't it make some sense to try to FIX it, rather than setting up a completely different server? perhaps someone with an idea of the problem and its solution will be able to chime in. -- My

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

Am 05.06.2011 23:49, schrieb ag...@airpost.net: > > On Sun, 05 Jun 2011 23:29 +0200, "Reindl Harald" > wrote: >> i would use a replication slave and stop him for consistent backups >> because dumb locks are not really a good solution independent >> if this works "normally" > > unfortunately, i

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

On Sun, 05 Jun 2011 23:29 +0200, "Reindl Harald" wrote: > i would use a replication slave and stop him for consistent backups > because dumb locks are not really a good solution independent > if this works "normally" unfortunately, i have no idea what that means. something's apparently broken w

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

On Sun, 05 Jun 2011 23:30 +0200, "Reindl Harald" wrote: > BTW > WHY is everybody ansering to the list AND the author of the last post? > this reults in get every message twice :-( Reply -> sends to ONLY the From == h.rei...@thelounge.net Reply to all sends to BOTH the From == h.rei...@thelounge.n

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

BTW WHY is everybody ansering to the list AND the author of the last post? this reults in get every message twice :-( Am 05.06.2011 23:26, schrieb ag...@airpost.net: > fwiw, others are seeing this. e.g., in addition to the two bugs i'd > already referenced, > > http://www.directadmin.com/forum/s

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

hm - bad i would use a replication slave and stop him for consistent backups because dumb locks are not really a good solution independent if this works "normally" Am 05.06.2011 23:26, schrieb ag...@airpost.net: > fwiw, others are seeing this. e.g., in addition to the two bugs i'd > already refer

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

fwiw, others are seeing this. e.g., in addition to the two bugs i'd already referenced, http://www.directadmin.com/forum/showthread.php?p=202053 and one http://qa.lampcms.com/q122897/Can-t-backup-mysql-table-with-mysqldump-SELECT-LOCK-TABL-command claims a solution "Add --skip-add-locks to

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

the grant statements does nobody interest maybe use phpmyadmin for a clearer display mysql> select * from mysql.user where user='root' limit 1; +---+--+---+-+-+-+-+-+---+

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

hi, On Sun, 05 Jun 2011 22:24 +0200, "Reindl Harald" wrote: > have you checked you permissions-table if all privileges are active for root i've got, mysql> show grants for 'root'@'localhost'; +--

Re: upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

have you checked you permissions-table if all privileges are active for root and have you started "ymsql_upgrade" after all updates? Am 05.06.2011 22:20, schrieb ag...@airpost.net: > i use ZRM to do backups of my databases. > > with v5.1.x, this works fine, > > mysql-zrm-scheduler --now --back

upgraded from 5.1->5.5. now getting a mysqldump ERROR "1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES". a bug or my config?

i use ZRM to do backups of my databases. with v5.1.x, this works fine, mysql-zrm-scheduler --now --backup-set manual --backup-level 0 to execute a manual backup. i recently upgraded from v5.1.x -> v5.5.12, mysqladmin -V mysqladmin Ver 8.42 Distrib 5.5.12, for Linux on i686 now, at exec

Re: Bug using 32-bit libmysqlclient on a 64-bit system?

It is basicly a not clever solution to run 32bit libs with a 64bit system. You have to compile -m32 and all sort of things. It is *way* better to compile with pure 64bit. re, wh Am 04.06.2011 02:18, schrieb Alex Gaynor: > I've got a 64-bit Linux system, with a 32-bit libmysqlclient (and a 64-bit

Bug using 32-bit libmysqlclient on a 64-bit system?

CHARACTER_SET_NAME: 142345400 COLLATIONS: 142345464 : 142345496 : 142345584 def: 1280069443 I'm not sure what the issue is, and it may very well be on my end, but any debugging help you can provide would be great (this was originally extracted from a bug in a Python MySQL driver I'm working on using the ctypes FFI). Thanks, Alex

Re: Interesting bug/oversight

- Original Message - > From: "Dan Nelson" > > I doubt that mysql calls anything other than gethostbyname() or > getaddrinfo(), so your behaviour is probably dependant on whatever OS > you are running and how often its local resolver re-checks resolv.conf. > Usually that's only once when a

Re: Interesting bug/oversight

strongly suspect that this is due to it > internally caching the nameserver, too, and not refreshing that along with > the host cache on a flush hosts command. > > Can anyone confirm this is the case, and wether or not a bug has been > logged about it? I can't seem to find one.

Re: Interesting bug/oversight

- Original Message - > From: "Claudio Nanni" > Consider also the DNS TTL. That should be irrelevant when changing DNS servers :-) > If you flush hosts in MySQL it'll ask again the OS to resolve a name > , but if that is still in the DNS cache it could return that 'old' > value instead

Re: Interesting bug/oversight

r a full restart did it pick itself up and start > doing proper lookups. I strongly suspect that this is due to it internally > caching the nameserver, too, and not refreshing that along with the host > cache on a flush hosts command. > > Can anyone confirm this is the case

Interesting bug/oversight

ching the nameserver, too, and not refreshing that along with the host cache on a flush hosts command. Can anyone confirm this is the case, and wether or not a bug has been logged about it? I can't seem to find one. -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is e

MySQL Community Server 5.6.2 has been released (part 2 - bug fixes)

Dear MySQL users, This is the list of bug fixes. For the functional enhancements, see part 1 of this mail: Bugs fixed: * Performance: InnoDB Storage Engine: An UPDATE statement for an InnoDB table could be slower than necessary if it changed a column covered by a prefix

Got It; Thank You; Re: Mysql Bug 04/01/11

Got It; Thank You, Thank You, Thank You On 4/1/2011 11:28 PM, Claudio Nanni wrote: Hi Thomas, Did you run the post install script? http://kae.li/iiikj Claudio On Apr 2, 2011 2:20 AM, "Thomas Dineen" > wrote:

Re: Mysql Bug 04/01/11

Am 02.04.2011 13:11, schrieb Claudio Nanni: > Reindl Harald, > > I would appreciate if you could please lower your tones. > and keep this list as professional as it has always been, this is not a > nerds forum. > > *Problem:* 110401 16:42:30 [ERROR] /usr/local/mysql/libexec/mysqld: Can't > find

Re: Mysql Bug 04/01/11: http://dev.mysql.com/doc/refman/5.0/en/starting-server.html

Am 02.04.2011 02:18, schrieb Thomas Dineen: > The following error occurs: > 110401 16:42:30 [ERROR] /usr/local/mysql/libexec/mysqld: Can't find file: > './mysql/host.frm' (errno: 13) BTW: you know google? "Can't find file: './mysql/host.frm' (errno: 13)" http://bugs.mysql.com/bug.php?id=1279

Re: Mysql Bug 04/01/11

Reindl Harald, I would appreciate if you could please lower your tones. and keep this list as professional as it has always been, this is not a nerds forum. There is always someone that knows more than you but he's not "shouting" at you everytime you say something wrong. If you think that a questi

Re: Mysql Bug 04/01/11

Am 02.04.2011 02:18, schrieb Thomas Dineen: >> Gentlemen: >> >> - Keep in mind that I have approximately 50 hours into this Mysql server >> install and still no >> results! what have you done the whole time? have you tried RTFM? we are not here to guide a blind one trough a basic setup becaus

Re: Mysql Bug 04/01/11

Hi, On 2-4-2011 2:18, Thomas Dineen wrote: Can't find file: './mysql/host.frm' (errno: 13) http://tinyurl.com/3sc3ydx -- Kind regards / met vriendelijke groet, Jigal van Hemert. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mys

Re: Mysql Bug 04/01/11

Hi Thomas, Did you run the post install script? http://kae.li/iiikj Claudio On Apr 2, 2011 2:20 AM, "Thomas Dineen" wrote:

Mysql Bug 04/01/11

Gentlemen: - Keep in mind that I have approximately 50 hours into this Mysql server install and still no results! - Regarding the Sun Freeware package mysql-5.0.67-sol10-x86-local.gz - When installed and started with the following command: /usr/local/mysql/bin/mysqld_safe --user=mysql & The

Re: mysql-5.0.67-sol10-x86-local Bug

Hi! Reindl Harald wrote: > Am 01.04.2011 04:28, schrieb Thomas Dineen: >> Gentle People: >> >> Using the following startup command: /etc/init.d/mysql.server start >> I get the following error: >> 110331 18:49:41 [ERROR] /usr/local/mysql/libexec/mysqld: Can't find file: >> './mysql/host.frm' (err

Re: mysql-5.0.67-sol10-x86-local Bug

'./mys > ql/host.frm' (errno: 13) > 110331 19:19:10 [ERROR] Fatal error: Can't open and lock privilege tables: > Can't > find file: './mysql/host.frm' (errno: 13) > 110331 19:19:10 mysqld ended > > root@Sun# > > > > > > > SE

mysql-5.0.67-sol10-x86-local Bug

n: >How-To-Repeat: >Fix: >Submitter-Id: >Originator:Owner >Organization: >MySQL support: [none | licence | email support | extended email support ] >Synopsis: >Severity: <[ non-critical | serious | critical ] (one line)> >Priority: <[ low | medium | h

Re: a crash bug

Hi zhongtao, thank you for reporting this bug. It has been filed as http://bugs.mysql.com/bug.php?id=60279 Regards, Roy On 24.02.11 08.08, tanzhongt wrote: create table t1(a int); create table t2(b int); PREPAREstmt FROM "select sum(b) from t2 group by b having b in (select b

a crash bug

Hi： I find a crash bug, version is mysql 5.5.8 Just try: use test; drop table if exists t1,t2; create table t1(a int); create table t2(b int); PREPAREstmt FROM "select sum(b) from t2 group by b having b in (select b from t1)"; execute stmt;

bug (or feature?) with mysqli_prepare

--+ 4 rows in set (0.00 sec) mysql> select version(); +-+ | version() | +-+ | 5.0.45-community-nt | +-+ 1 row in set (0.00 sec) How i can use mysqli_prepare to work properly with the first procedure? Maybe it was fixed in new versions or it's not a bug?

Re: Very slow subselect (parser bug)?

On Mon, Mar 15, 2010 at 4:22 PM, Pascal Gienger < pascal.gien...@uni-konstanz.de> wrote: > Using this result to reconstruct the first left outer join from the initial > statement, I get this result: > Not so much a bug as a missing feature: the parser is currently unable t

  1   2   3   4   5   6   7   8   9   10   >