I tested everything with 5.0.18 and 5.0.19 (and it rocks!),
but when I moved to 5.0.21 for pre-production testing, my
test query kills the server with the message below. Even
the "explain" query kills the server. I even emptied the
entire table of data, and the query still crashes. I
recreated the table without any index keys, still no dice.
Which forum should I be in? I don't see a bugs forum. I
guess I'll just backtrack to an older version...
Reduced testcase:
create table z (x date);
select date_sub(x, interval (weekday(x)%7) day) from z group by date_sub(x, interval (weekday(x)%7) day);
EDIT: I filed a confirmed bug:
http://bugs.mysql.com/bug.php?id=19832
Thanks!
Jason
060515 14:18:02 [Warning] Changed limits: max_open_files: 1024 max_connections: 1014 table_cache: 64
060515 14:18:02 InnoDB: Started; log sequence number 0 43665
060515 14:18:02 [Note] libexec/mysqld: ready for connections.
Version: '5.0.21' socket: '/raid/verifdb/mysql-5.0.21-amd64/mysql.sock' port: 3307 Source distribution
[query executed here]
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=8388600
read_buffer_size=131072
max_used_connections=1
max_connections=1014
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2214648 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Edited 4 time(s). Last edit at 05/16/2006 11:58AM by jayrusman.