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
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.
<<<
Hi Rick,
Thank you for continuing this. It brings up a few good points.
On 5/24/2013 12:17 PM, Rick James wrote:
For years (even decades), I have stayed out of trouble by assuming a 'date'
represents the instant in time corresponding to midnight at the start of that
day. In MySQL (until 5.6)
g
event, an appointment (potentially in a diff timezone), train schedule, etc.
> -Original Message-
> From: shawn green [mailto:shawn.l.gr...@oracle.com]
> Sent: Friday, May 24, 2013 6:50 AM
> To: mysql@lists.mysql.com
> Subject: 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
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` = DATE(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.
> 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
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 (i.
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
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
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 there's no
> time between
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
No worries!
I think I would have figured that out!
I'll feedback you tomorrow.
Thanks again
Claudio
2011/6/15 Hank
> Oops... big typo in above steps... add the following line:
>
> replicate-ignore-table=db.log
>
> to the SLAVE my.cnf, and restart the SLAVE server.
>
> The master does not ne
Oops... big typo in above steps... add the following line:
replicate-ignore-table=db.log
to the SLAVE my.cnf, and restart the SLAVE server.
The master does not need to be restarted or changed. Just the SLAVE.
Sorry about that.
-Hank Eskin
On Wed, Jun 15, 2011 at 5:19 PM, Claudio Nanni wro
Great investigation Hank,
congratulations.
I will try this tomorrow morning(11:20pm now) and let you know if I can
reproduce it on my environments.
Thanks!
Claudio
2011/6/15 Hank
> Two additional notes:
>
> 1. Using the "replicate-wild-ignore-table" option in my.cnf produces the
> same res
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,
this bug goes away and correct res
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.
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 more
> information as to what's causing i
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, everything works perfectly, u
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 test
values (1,null)" to replicate, but wh
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" wrote:
> > Both my master a
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_threads=0*/;
> /*!50003 SET @OLD_COMPLET
Both my master and slave bin logs look OK (I think)..
master bin log:
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
SET TIMESTAMP=1308012505/*!*/;
SET @@session.pseudo_thread_id=9/*!*/;
SET
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, because on
the slave error
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 All,
>
> I have a 64bit, 5.5.8
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.. but when
this st
i used mysql_tzinfo_to_sql utility to create timezone_* database after
upgrading zoneinfo in my host.
after that i am seeing this mismatch.
'America/Sao_Paulo' (http://www.timeanddate.com/worldclock/city.html?n=233) and
'America/Buenos_Aires' (http://www.timeanddate.com/worldclock/city.html?n
of whether it is for MyISAM or
> InnoDB, will come through during a mysqldump.
>
>
> ------
>
> *From:* Mark Maunder [mailto:[EMAIL PROTECTED]
> *Sent:* Tuesday, August 05, 2008 12:17 PM
> *To:* Rolando Edwards
> *Cc:* mysql@lists.mysql.com
>
h during a mysqldump.
From: Mark Maunder [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 05, 2008 12:17 PM
To: Rolando Edwards
Cc: mysql@lists.mysql.com
Subject: Re: Possible bug in mysqldump?
Thanks for the reply Rolando.
In both the examples I provided (pipe and t
se --master-data in the mysqldump
>
> 5) In mysql session 2, run "CHANGE MASTER TO MASTER_LOG_FILE=' from SHOW MASTER STATUS>,MASTER_LOG_POS=' STATUS>';"
>
> 6) In mysql session 2,run 'START SLAVE'.
>
> 7) In mysql session 1, run 'UNLOCK TA
5) In mysql session 2, run "CHANGE MASTER TO MASTER_LOG_FILE=',MASTER_LOG_POS='';"
6) In mysql session 2,run 'START SLAVE'.
7) In mysql session 1, run 'UNLOCK TABLES'
Give it a try !!!
-Original Message-
From: Mark Maunder [mailto:[EMAIL PROTECTED]
Se
Hi all,
I'm busy setting up replication and have encountered what looks like a bug
in mysqldump. The following commands work perfectly:
Running the following commands in the mysql client on the slave:
stop slave;
reset slave;
create database dbName;
CHANGE MASTER TO MASTER_HOST='
db and can't create database but when i
tried creating db?dbname the database was created though it didn't allow the
user to create any other database. I created this database using phpmyadmin.
Is it a bug in mysql?
In case i am not using special character '_' (underscore), I am no
On Wednesday 11 July 2007 00:34, Anders Karlsson wrote:
> UNION will only return distinct rows. This is according to spec and to
> the SQL Standard.
And of course, to no one's surprise, this also matches the mathematical
definition of union:
j
--
Joshua Kugler
Lead
UNION is mean to removed duplicate rows. Use "UNION ALL" if you don't want
this to happen.
http://dev.mysql.com/doc/refman/5.0/en/union.html
-Original Message-
From: list account [mailto:[EMAIL PROTECTED]
Sent: 11 July 2007 09:19
To: mysql@lists.mysql.com
Subjec
INCT nor ALL is
specified then.
Cheers
/Karlsson
list account wrote:
Hi all,
I believe to have found a bug in MySQL's union implementation. Can
someone
confirm this, please or convince me that this is not a buggy behaviour of
mysql :
UNION seems to behave like DISTINCT by default:
mysql>
Hi all,
I believe to have found a bug in MySQL's union implementation. Can someone
confirm this, please or convince me that this is not a buggy behaviour of
mysql :
UNION seems to behave like DISTINCT by default:
mysql> select 2 c1
-> union
-> select 1 c1
-> union
guys,
strange things happen when using COUNT() in subqueries. even the use of
HAVING in a SELECT statement turns up a weired result, as it should work
on the result set and should be filtered while rows are returned to the
client.
(you can find the selects and stuff in a more readable way on
http
I just filed bug #22317 about this. The following script fails to
return a row under 4.1.21 (on x86_64, anyway), but works correctly on
4.1.20 (and .18):
drop table if exists test1;
create table test1
(
datetimeval datetime,
dateval1 date,
dat
In the last episode (Aug 31), Renald Buter said:
> On 12:27 Thu 31 Aug , Duncan Hill wrote:
> > On Thursday 31 August 2006 12:21, Renald Buter wrote:
> > > The problem is that a simple 1-table query shows different
> > > answers depending on whether you select 1 or 2 columns.
>
> *blush*
>
>
On 12:27 Thu 31 Aug , Duncan Hill wrote:
> On Thursday 31 August 2006 12:21, Renald Buter wrote:
>
> > The problem is that a simple 1-table query shows different answers
> > depending on whether you select 1 or 2 columns.
*blush*
Of course. I see. How stupid.
Thanks and sorry to have bother
On Thursday 31 August 2006 12:21, Renald Buter wrote:
> The problem is that a simple 1-table query shows different answers
> depending on whether you select 1 or 2 columns.
Relational databases are founded on mathematical set theory. Unless you
specify an ORDER BY stanza in your query, the data
On 11:34 Thu 31 Aug , Renato Golin wrote:
> Renald Buter wrote:
> >Odd, eh? But what's worse, the JOIN between this column and other
> >columns *also* uses this truncated values and the result is bogus.
>
> I wouldn't say odd, as you didn't specified any order I wouldn't rely on
> the order o
Renald Buter wrote:
Odd, eh? But what's worse, the JOIN between this column and other
columns *also* uses this truncated values and the result is bogus.
I wouldn't say odd, as you didn't specified any order I wouldn't rely on
the order of the output. Try ordering things for what you want and
Hello list,
I've found this strange select bug in retrieving rows from a table. I
can best illustrate this with an output of two queries:
mysql> select id,jn from paper_2001 limit 10;
+--+---+
| id | jn|
+--+---+
| 19360350 | 6165 |
| 19360351
[I searched the bug database...please let me know if I missed an already filed
or fixed bug.]
I am trying to dump a database from MySQL 4.0.24 using the client tools from
5.0. Debian server, Ubutnu 6.06 client.
I use this command line (watch for wrap):
mysqldump -u jkugler -p -h
dbserver --a
kmh496 wrote:
hi,
i am running a join query between the german_english table and the
user_todo_german_english tables, to figure out which words a user is
studying.
the key i am using is a combination of wordid + pos + posn (that is part
of speech == pos)
however, i am not able to correctly do the
2006-04-22 (토), 00:49 +0100, Philippe Poelvoorde 쓰시길:
> Hi,
>
> > mysql> select * from user_todo_german_english where wordid = '86851' and
> > posn = '1' and pos = 'm' AND mb_id='curious';
> > +-++--+--+-+
> > | mb_id | wordid | posn | pos | date_col
2006-04-22 (토), 08:43 +0900, kmh496 쓰시길:
> hi,
> i am running a join query between the german_english table and the
> user_todo_german_english tables, to figure out which words a user is
> studying.
> the key i am using is a combination of wordid + pos + posn (that is part
> of speech == pos)
> how
Hi,
> mysql> select * from user_todo_german_english where wordid = '86851' and
> posn = '1' and pos = 'm' AND mb_id='curious';
> +-++--+--+-+
> | mb_id | wordid | posn | pos | date_col|
> +-++--+--+-
hi,
i am running a join query between the german_english table and the
user_todo_german_english tables, to figure out which words a user is
studying.
the key i am using is a combination of wordid + pos + posn (that is part
of speech == pos)
however, i am not able to correctly do the join because of
Interesting... maybe this is because the fill is not actualy stored in the
database... and being sorted/compared as a number MySQL removes the ZEROFILL
!
You can go and do:
select BINARY * from a
union
select BINARY * from a;
--
Gabriel PREDA
Senior Web Developer
On 2/14/06, Juri Shimon <[EMAIL
Hello mysql,
Union on zerofilled fields eats 'zerofilling'.
How to repeat:
> create table a (id integer zerofill);
> insert into a values(1),(2),(3);
> select * from a;
++
| id |
++
| 01 |
| 02 |
| 03 |
++
> select * from a u
Privet!
This seems as a bug, especially because with InnoDB tables bulk
insert works fine. You may add your comments at:
http://bugs.mysql.com/bug.php?id=16021
Juri Shimon wrote:
> Hello mysql,
>
> When trigger on table uses select from same table, then bulk insert into
> t
Hello mysql,
When trigger on table uses select from same table, then bulk insert into
this table cause error.
How to repeat:
create table t(i int not null, j int not null, n numeric(15,2), primary
key(i,j));
create table s(i int not null, n numeric(15,2), primary key(i));
delimiter //
crea
Octavian Rasnita wrote:
From: "Gleb Paharenko" <[EMAIL PROTECTED]>
Hello.
In my opinion, it is not a bug. REPLACE has returned the sum
of affected rows - one was deleted, and one was inserted. See:
http://dev.mysql.com/doc/refman/5.1/en/replace.html
Thank you. I have seen that's the true.
I
From: "Gleb Paharenko" <[EMAIL PROTECTED]>
> Hello.
>
> In my opinion, it is not a bug. REPLACE has returned the sum
> of affected rows - one was deleted, and one was inserted. See:
> http://dev.mysql.com/doc/refman/5.1/en/replace.html
>
>
Thank you. I have seen that's the true.
Is there any
Hello.
In my opinion, it is not a bug. REPLACE has returned the sum
of affected rows - one was deleted, and one was inserted. See:
http://dev.mysql.com/doc/refman/5.1/en/replace.html
Octavian Rasnita wrote:
> Hi,
>
> I have tried:
>
> mysql> create table z(id int unsigned not n
Hi,
I have tried:
mysql> create table z(id int unsigned not null primary key, first_name
varchar(20), last_name varchar(20));
Query OK, 0 rows affected (0.06 sec)
mysql> insert into z values(1, 'John', 'Smith'), (2, 'George',
'Washington');
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplica
Hello.
Manual says that --replicate-do-db:
" Tells the slave to restrict replication to statements where the
default database (that is, the one selected by USE) is db_name."
Note that this does not replicate cross-database statements, check
what is your default database, when you're running
More investigation shows that the query does make it to the slave, at
least into the relay log, yet it's still ignored. 'replicate-do-db' is set
and shows the correct DB in the slave status.
Atle
-
Flying Crocodile Inc, Unix Systems Administrator
On Thu, 20 Oct 2005, Atle Veka wrote:
> I ran in
Hello.
> the query entered into the binlog, however the slave ignores it >silently:
Check your server's relay logs if they contains this statement. See:
http://dev.mysql.com/doc/refman/5.0/en/replication-problems.html
http://dev.mysql.com/doc/refman/5.0/en/slave-logs.html
Check that
I ran into a problem on a replication setup, where if you issue the
following CREATE statement on the master the table will get created and
the query entered into the binlog, however the slave ignores it silently:
CREATE TABLE `db`.`table` (a INT DEFAULT 0)
I have duplicated this exact iss
Peter Brawley <[EMAIL PROTECTED]> wrote on 10/12/2005 04:27:18
PM:
> James,
>
> Both ...
>
> SELECT ...
> FROM a, b LEFT JOIN c ON a.x=c.y
>
> and
>
> SELECT ...
> FROM a
> LEFT JOIN B USING (x )
> LEFT JOIN c ON a.x=c.y
>
> work up to and including version 5.0.10, not in 5.
James,
Both ...
SELECT ...
FROM a, b LEFT JOIN c ON a.x=c.y
and
SELECT ...
FROM a
LEFT JOIN B USING (x )
LEFT JOIN c ON a.x=c.y
work up to and including version 5.0.10, not in 5.0.11, 12 or 13.
http://bugs.mysql.com/bug.php?id=13832 reports...
"The two statements below
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
> SELECT...
> FROM items i
> INNER JOIN nams.netids n
> INNER JOIN ...
> ...
> Does the problem remain? If it goes away, this would be useful information
> to include in your bug report.
Thank you for the suggestion, but
James Black <[EMAIL PROTECTED]> wrote on 10/12/2005 02:06:26 PM:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Peter Brawley wrote:
> > James,
> >
> > You can reproduce that error by writing ...
> >
> > SELECT ...
> > FROM a, b INNER JOIN c ON a.x=c.y
> >
> > The error goes away if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Brawley wrote:
> James,
>
> You can reproduce that error by writing ...
>
> SELECT ...
> FROM a, b INNER JOIN c ON a.x=c.y
>
> The error goes away if you instead write ...
>
> SELECT ...
> FROM b, a INNER JOIN c ON A.x=c.y
>
> so you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Brawley wrote:
> James,
>
> You can reproduce that error by writing ...
>
> SELECT ...
> FROM a, b INNER JOIN c ON a.x=c.y
>
> The error goes away if you instead write ...
>
> SELECT ...
> FROM b, a INNER JOIN c ON A.x=c.y
I will t
James,
You can reproduce that error by writing ...
SELECT ...
FROM a, b INNER JOIN c ON a.x=c.y
The error goes away if you instead write ...
SELECT ...
FROM b, a INNER JOIN c ON A.x=c.y
so you might try swapping
FROM items i
, nams.netids n
PB
-
[EMAIL PROTECTED] wrote:
James Black <[EMAIL PROTECTED]> wrote on 10/12/2005 09:57:51 AM:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Due to the complexity of my query I don't know how to get this down to a
> simple test case to demonstrate the error.
>
> This works under mysql 4.1.8 btw, so it is failing due
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Due to the complexity of my query I don't know how to get this down to a
simple test case to demonstrate the error.
This works under mysql 4.1.8 btw, so it is failing due to a change
introduced recently. It also worked under mysql 5.0.9, but I haven'
Hello.
Support guys verified this bug. Thank you. See:
http://bugs.mysql.com/bug.php?id=13815
Juri Shimon wrote:
> Hello All!
>
> left(),right(),mid(),etc functions
> +
> with fixed point return value for function (or out parameter for sp)
> ---
> result has been
Hello All!
left(),right(),mid(),etc functions
+
with fixed point return value for function (or out parameter for sp)
---
result has been truncated
How to repeat:
mysql> drop function if exists test;
mysql> drop function if exists test1;
mysql> delimiter //
mysq
Dyego Souza Dantas Leal wrote:
Hello Guys,
I'm using the 5.0.12 version of MySQL PRO on AMD64 3000+ with 1 GB of
ram and using the InnoDB Tables..
Here is the Select:
mysql> select f1.fc_package from svcs_filecontrol f1 where f1.fc_id in (
-> *select max(f2.fc_id) from svcs_filecontr
Hello Guys,
I'm using the 5.0.12 version of MySQL PRO on AMD64 3000+ with 1 GB of
ram and using the InnoDB Tables..
Here is my table:
CREATE TABLE `svcs_filecontrol` (
`fc_id` int(10) unsigned NOT NULL auto_increment,
`fc_us_id_lockby` int(10) unsigned default NULL,
`fc_lbl_id` int(10) un
>Description:
There appears to be a type promotion problem involving sql statements which
include a 'between' comparison and a decimal type field is one of the operands.
>How-To-Repeat:
CREATE TABLE `foo1` (
`test1` decimal(7,2) NOT NULL default '0.00',
`test2` decimal(7,2) NOT NULL defau
I have confirmed that this problem exhibits itself on the Mysql AB
compiled binaries that are compiled with gcc, both Standard and Max, but
does _not_ exhibit itself on the Mysql AB binary built with the Intel C++
Compiler 8.1 (mysql-standard-4.1.12-pc-linux-gnu-i686-icc-glibc23.tar.gz).
I have al
Arjen Lentz wrote:
[...]
While we're at it: the term "non-zero"... what does it mean? As we all
know, NULL != 0, and 0 == zero, consequently NULL must be non-zero.
Flawed logic.
Yes, I used flawed logic to illustrate my point: "non-zero" is a bad
term to use in this context.
The text from the
ember Venn diagrams from highschool? The circles with
numbers in them, circles can overlap, etc... the realm of valid data of
a type is enclosed in a circle, like 0-255 for a TINYINT. NULL is not
part of that set, it falls outside the realm.
You can't make any ordinary comparison with NU
Hi!
If you have put:
innodb_file_per_table
in your my.cnf or my.ini in Windows, and try to run MySQL-4.1.9, the mysqld
server exits and prints:
"
050117 3:07:59 InnoDB: Operating system error number 87 in a file
operation.
"
to the .err log.
You can work around the bug in 4.1.9
Bruce Dembecki wrote:
At the 2004 Users Conference in Orlando in April there were two sessions on
optimizing MySQL hosted by a MySQL staffer who's name eludes me for the
moment.
Peter Zaitsev I believe. He did some InnoDB performance tuning sessions.
He told the assembled masses that in benchmark
Hi Bruce,
On Dec 28, 2004, at 2:38 PM, Bruce Dembecki wrote:
As a person in the process of migrating from 4.0 to 4.1 and having
already
scheduled the downtime with my clients for this Friday morning, and
having
to do a full dump and import already as part of the migration process
I'd
like to kno
L and contributing to it's development.
Best Regards, Bruce
On 1/6/05 7:38 AM, "Ken Menzel" <[EMAIL PROTECTED]> wrote:
> Hi Bruce
>
>
> - Original Message -
> From: "Bruce Dembecki" <[EMAIL PROTECTED]>
> To:
> Sent: Thursday
Hi Bruce
- Original Message -
From: "Bruce Dembecki" <[EMAIL PROTECTED]>
To:
Sent: Thursday, December 30, 2004 2:51 AM
Subject: Re: Fixing "the worst InnoDB corruption bug in 3 years" -
when
As a side note with demonstrated performance increases when using
t; <[EMAIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Thursday, December 30, 2004 9:51 AM
Subject: Re: Fixing "the worst InnoDB corruption bug in 3 years" - when
Thanks Heikki, I understand the bug, and I know you fixed it, for which I
a=
m
very pleased, as always problems
sorry
--
-- -- -- --
Sayusi Ando
-- -- -- --
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
;
> On 12/28/04 2:38 PM, "Bruce Dembecki" <[EMAIL PROTECTED]> wrote:
>
>> In the MySQL Manual under InnoDB in the "Using Per-Table Tablespace" section
>> it says clearly at the top:
>>
>> NOTE: CRITICAL BUG in 4.1 if you specify innodb_file_per_t
ummer 2001. Fortunately, the bug affects few users, because not too many
are running with innodb_file_per_table.
Regards,
Heikki
..
List: mysql
Subject:Fixing "the worst InnoDB corruption bug in 3 years" - when
From: Bruce Dembecki
Date: 2004-12-28 22:38:36
Me
Hi, Peter!
* Peter Valdemar M?rch <[EMAIL PROTECTED]> [04/12/28 17:33]:
> Hi there,
>
> A bug was fixed in 4.0.23:
> >* Fixed bug which caused FROM_UNIXTIME() function to return wrong
> > result if the argument was too big.
> >http://bugs.mysql.com/6439
>
> However, it looks like it has si
In the MySQL Manual under InnoDB in the "Using Per-Table Tablespace" section
it says clearly at the top:
NOTE: CRITICAL BUG in 4.1 if you specify innodb_file_per_table in `my.cnf'!
If you shut down mysqld, then records may disappear from the secondary
indexes of a table. See (Bug
Hi there,
A bug was fixed in 4.0.23:
* Fixed bug which caused FROM_UNIXTIME() function to return wrong
result if the argument was too big.
http://bugs.mysql.com/6439
However, it looks like it has side effects:
select FROM_UNIXTIME(0) returns "1970-01-01 01:00:00" in 4.0.22 but NULL
in 4.0.2
e inserts end up in the insert buffer. Shut down mysqld quickly. At the
next startup the table is corrupt.
Suggested fix:
Will be fixed in 4.1.9. We let InnoDB do a 'crash-like' startup always.
This is the worst InnoDB corruption bug in 3 years. I apologize that it
slipped thr
Hi Vlad !
Why not using
select (select min( a ) is null from a) or null;
as a workaround ?
Regards,
Jocelyn
- Original Message -
From: "Vlad Shalnev" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 03, 2004 7:01 AM
Subject: Re:
Sergei Golubchik wrote:
Hi!
On Dec 02, Vlad Shalnev wrote:
Looks like a bug.
Could you submit a bugreport at http://bugs.mysql.com ?
I've submitted a bugreport.
Downgrade to 3.23 and wait for this problem solving.
Thanks for all
It happens after upgrade from 3.23.46.
mysql> create table a ( a i
At 11:42 -0500 12/2/04, Michael Stassen wrote:
Roger Baklund wrote:
This is (as I see it) a documentation issue, I was not trying to
say that Vlad was "wrong".
Right, that's why I'm copying the docs list.
I updated the description to account for the cases when there are 1 or 2
NULL operands. It
I upgraded from 5.01 to 5.02 and now I am getting the error localhost is not
allowed to connect to this MySQL server. What should I do, root cannot
connect a well. I'm currently using win32 and have old-passwords in my.cnf
Thanks
--
MySQL General Mailing List
For list archives: http://lists.mys
Roger Baklund wrote:
This is (as I see it) a documentation issue, I was not trying to say
that Vlad was "wrong".
Right, that's why I'm copying the docs list.
While we're at it: the term "non-zero"... what does it mean? As we
all know, NULL != 0, and 0 == zero, consequently NULL must be non-zero
> -Original Message-
> From: Roger Baklund [mailto:[EMAIL PROTECTED]
> This definition (from the manual) is self-contradicting: 1 OR NULL
> should evaluate to 1 because "any operand is non-zero", but it should
> also evaluate to NULL because "any operand is NULL".
>
> http://dev.mysql.c
1 - 100 of 567 matches
Mail list logo
