mysql 4.0.8 dies at "start slave"

am 10.01.2003 03:04:36 von Johannes Ullrich

Platform: RedHat 7.3, Mysql 4.0.8 installed via RPM. No prior
mysql installation on this machine (clean RH 7.3 install)

Hardware: dual intel pIII, 4 Gig RAM

mysql dies immidiatly after 'start slave'. Prior to this, replication
was working. Sequence of events:

- started mysql (and replication)
- replication stopped due to missing table on slave
- loaded table using 'load table ... from master'
(master is running 3.23.53a-Max )
- after table was loaded, issued
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; slave start;

-> mysqld crashed.

How-To-Repeat:
start mysql (either using safe_mysqld or not) and it will
now crash right away after it crashed in this manner. Stack traces
are identical.

backtrace resolved shows an error reading even from relay log:

0x807328a handle_segfault + 450
0x82834b8 pthread_sighandler + 184
0x80b36ce exec_event__14Load_log_eventP6st_netP17st_relay_log_info + 1074
0x80b408e exec_event__22Execute_load_log_eventP17st_relay_log_info + 374
0x80ecaa1 exec_relay_log_event__FP3THDP17st_relay_log_info + 541
0x80edb61 handle_slave_sql + 597
0x8280c6c pthread_start_thread + 220
0x82b620a thread_start + 4

if run from strace, last few lines ahead of the error message:

sched_getscheduler(0x504c) = 0
sched_getparam(0x504c, 0xbffff6f8) = 0
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
select(5, [3 4], NULL, NULL, NULL030109 20:57:48 Slave I/O thread: connected to master 'repl@salvedb:3307', replication started in log 'sr44-bin.003' at position 123375503
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries
....

key_buffer_size=209715200
read_buffer_size=209711104
sort_buffer_size=209715192
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3415663 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x873ad10
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbfe5f2b8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x807328a
0x82834b8
0x80b36ce
0x80b408e
0x80ecaa1
0x80edb61
0x8280c6c
0x82b620a

Content of relay-log-info
-------------
11654531
x440-bin.003
96291803

------

instruction #11654531 from relay-bin log:

# at 11650620
#030109 2:36:44 server id 7 log_pos 96287892
#Append_block: file_id: 1 block_len: 3888
# at 11654531
#030109 2:36:44 server id 7 log_pos 96287892
#Exec_load: file_id=1

tail of error log:

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=209715200
read_buffer_size=209711104
sort_buffer_size=209715192
max_used_connections=3
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3415663 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8758710
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbfddf2b8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x807328a
0x82834b8
0x80b36ce
0x80b408e
0x80ecaa1
0x80edb61
0x8280c6c
0x82b620a
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=1396

Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 1396 did to cause the crash. In some cases of really
bad corruption, the values shown above may be invalid.

The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0

--
------------------------------------------------------------ --------
jullrich@euclidian.com Collaborative Intrusion Detection
join http://www.dshield.org

---end of your message-------

MySQL Development Team

--
------------------------------------------------------------ --------
jullrich@euclidian.com Collaborative Intrusion Detection
join http://www.dshield.org

------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread13442@lists.mysql.com
To unsubscribe, e-mail

Re: mysql 4.0.8 dies at "start slave"

am 10.01.2003 15:49:38 von Guilhem Bichot

>
> 1 - started mysql, copied tables using 'load data table.. from master"
> 2 - turned on replication
> mysql ran ok for a few hours until it hit the statement shown above.
> 3 - slave stopped due to missing table.
> 4 - transfered table (completed ok without error messages to console)
> 5 - skipped the broken statement (it was no longer required to execute
> after the transfer)
> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; slave start;
> 6 - entered 'start slave' and it crashed immediatly.

> BTW: I also found these entries in my error log:
>
>
> 030109 2:30:13 Error in Log_event::read_log_event(): 'Event too big',
> data_len=942681393,event_type=48 030109 2:30:13 Error in
> Log_event::read_log_event(): 'Event too big',
> data_len=154679344,event_type=56 030109 2:30:13 Error in
> Log_event::read_log_event(): 'Event too big',
> data_len=822685753,event_type=48 030109 2:30:13 Error in
> Log_event::read_log_event(): 'Event too big',
> data_len=942747950,event_type=54 030109 2:30:13 Error in
> Log_event::read_log_event(): 'Event too big',
> data_len=909189176,event_type=74 030109 2:30:13 Error in
> Log_event::read_log_event(): 'Event too big',
> data_len=1279610450,event_type=50

These 'Event too big' entries are worrying : your slave was not able to read
(and execute) some instructions (called events) from the master's binlog,
hence he probably became out of sync with the master from that moment. What
is the instruction which caused these messages ? Was it a LOAD DATA INFILE ?
If it was a LOAD DATA INFILE, then :
- what is the type of the table you loaded in (MyISAM, InnoDB,...)
- If it was transactionnal (InnoDB, BDB), was the LOAD inside a transaction
(BEGIN, LOAD, COMMIT
or
SET AUTOCOMMIT=0, LOAD) or not ?
- What is the value of max_allowed_packet on your slave
(show variables like 'max_allowed_packet') ?
- Do your master's binlogs have a size of approximately 1G ?

> > > Content of relay-log-info
> > > -------------
> > > 11654531
> > > x440-bin.003
> > > 96291803
> > >
> > > ------
> > >
> > > instruction #11654531 from relay-bin log:
> > >
> > > # at 11650620
> > > #030109 2:36:44 server id 7 log_pos 96287892
> > > #Append_block: file_id: 1 block_len: 3888
> > > # at 11654531
> > > #030109 2:36:44 server id 7 log_pos 96287892
> > > #Exec_load: file_id=1
> > >

I can't figure out the instruction that caused the above Append_block and
Exec_load. I mean I have tested your sequence with a 3.23.54 master and 4.0.9
slave, and I never got such instructions in the relay-log (LOAD TABLE FROM
MASTER is not logged in the master's binlog or in the slave's relay log).
What caused these Append_block and Exec_load ? Is it some
LOAD DATA INFILE ??

--
For technical support contracts, visit https://order.mysql.com/?ref=mgbi
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Guilhem Bichot
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Software Developer
/_/ /_/\_, /___/\___\_\___/ Bordeaux, France
<___/ www.mysql.com +33 5 56 88 34 39

------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread13451@lists.mysql.com
To unsubscribe, e-mail

Re: mysql 4.0.8 dies at "start slave"

am 10.01.2003 16:21:19 von Johannes Ullrich

Re: mysql 4.0.8 dies at "start slave"

am 10.01.2003 17:03:43 von Guilhem Bichot

> > > Log_event::read_log_event(): 'Event too big',
> > > data_len=909189176,event_type=74 030109 2:30:13 Error in
> > > Log_event::read_log_event(): 'Event too big',
> > > data_len=1279610450,event_type=50

127961045 > 526MB and event types 74 and 50 do not exist.
This shows that your slave was very probably reading data at a wrong position
in the master's binlog.
Probably this is some bug with the handling of LOAD DATA INFILE statements
from a _3.23_ master by a _4.0_ slave. Probably a mismatch between the format
of the LOAD in the master's binlog and the format expected by the slave.
I will inspect this.

> > These 'Event too big' entries are worrying : your slave was not able to
> > read (and execute) some instructions (called events) from the master's
> > binlog, hence he probably became out of sync with the master from that
> > moment. What is the instruction which caused these messages ? Was it a
> > LOAD DATA INFILE ? If it was a LOAD DATA INFILE, then :
> > - what is the type of the table you loaded in (MyISAM, InnoDB,...)
>
> MyISAM
>
> > - If it was transactionnal (InnoDB, BDB), was the LOAD inside a
> > transaction (BEGIN, LOAD, COMMIT
> > or
> > SET AUTOCOMMIT=0, LOAD) or not ?
>
> was non transactional
>
> > - What is the value of max_allowed_packet on your slave
> > (show variables like 'max_allowed_packet') ?
>
> slave: 10484736 (mysql 4.0.8)
> master: 10484736 (mysql 3.23.53a-Max)
>
> > - Do your master's binlogs have a size of approximately 1G ?
>
> no. largest one is 526 MByte, the one that was running as the
> crash occured is now at 119M and was probably quite a bit
> smaller (50MByte?) at the time of the crash
>
> BTW: The table I did try to transfer is now at 5Gig, was probably
> around 4Gig as I did the transfer.
>
> > > > > Content of relay-log-info
> > > > > -------------
> > > > > 11654531
> > > > > x440-bin.003
> > > > > 96291803
> > > > >
> > > > > ------
> > > > >
> > > > > instruction #11654531 from relay-bin log:
> > > > >
> > > > > # at 11650620
> > > > > #030109 2:36:44 server id 7 log_pos 96287892
> > > > > #Append_block: file_id: 1 block_len: 3888
> > > > > # at 11654531
> > > > > #030109 2:36:44 server id 7 log_pos 96287892
> > > > > #Exec_load: file_id=1
> >
> > I can't figure out the instruction that caused the above Append_block and
> > Exec_load. I mean I have tested your sequence with a 3.23.54 master and
> > 4.0.9 slave, and I never got such instructions in the relay-log (LOAD
> > TABLE FROM MASTER is not logged in the master's binlog or in the slave's
> > relay log). What caused these Append_block and Exec_load ? Is it some
> > LOAD DATA INFILE ??
>
> A 'LOAD DATA INFILE' was executed on the master. maybe this is a record of
> the replicated event? This 'LOAD DATA INFILE' imports an approx
> 100MByte-1+Gig file into the 'reports' table.

I need to understand if this LOAD DATA INFILE was done near the failing
INSERT INTO oldreports SELECT * FROM reports where
date Was it :
INSERT INTO oldreports SELECT * FROM reports ... ->FAILS,
LOAD TABLE FROM MASTER,
and _immediately_after_,
LOAD DATA INFILE

?

--
For technical support contracts, visit https://order.mysql.com/?ref=mgbi
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Guilhem Bichot
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Software Developer
/_/ /_/\_, /___/\___\_\___/ Bordeaux, France
<___/ www.mysql.com +33 5 56 88 34 39

------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread13453@lists.mysql.com
To unsubscribe, e-mail

Re: mysql 4.0.8 dies at "start slave"

am 10.01.2003 21:18:28 von Johannes Ullrich

To nail this down, I started over 'from scratch' and was able to reproduce
the crash. This time, no 'Event too big' entries in my log file. (find the
complete error log below). The stack trace is identical, giving me some
confidence that I hit the same bug again.

The sequence of events was a bit different this time. It took quite a while
after the large table got transfered for mysqld to die. So I think the
transfer is not the issue here, but some other replication problem.

I think now that the issue is related to the replication of 'LOAD DATA INFILE',
as it looks like the slave crashed again trying to replicate this statement.

--------------- bin log ---------------------

# at 4
#030110 10:53:20 server id 8 log_pos 4 Start: binlog v 3, server v 4.0.8-gamma-log created 030110 10:53:20
# at 79
#030110 11:06:40 server id 8 log_pos 79 Query thread_id=3 exec_time=0 error_code=0
use dshield;
SET TIMESTAMP=1042214800;
drop table reports;
# at 135
#030110 11:07:53 server id 8 log_pos 135 Query thread_id=3 exec_time=2 error_code=0
SET TIMESTAMP=1042214873;
drop table oldreports;
# at 194
#030110 12:26:27 server id 8 log_pos 194 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=1042219587;
CREATE TABLE reports (
date date NOT NULL default '0000-00-00',
time time default '12:00:00',
author int(11) unsigned default NULL,
count int(11) unsigned NOT NULL default '0',
source varchar(15) NOT NULL default '',
sourceport int(10) unsigned default NULL,
target varchar(15) default NULL,
targetport int(11) unsigned default NULL,
protocol tinyint(3) unsigned default NULL,
flags varchar(10) default NULL,
logs blob,
id bigint(20) NOT NULL auto_increment,
PRIMARY KEY (id),
KEY report_date (date),
KEY report_source (source),
KEY report_author (author),
KEY reports_targetport (targetport)
) TYPE=MyISAM MAX_ROWS=50000000 AVG_ROW_LENGTH=150;

-------------- relay.log.info ------------

../sundown-relay-bin.001
749372
xx44-bin.001
713597

---------- xx44-bin.001 around '713597' (note, 713597 doesn't exist) ---

# at 713473
#030110 13:53:12 server id 7 Query thread_id=264984 exec_time=0
error_code=0
SET TIMESTAMP=1042224792;
update banner_stats set exposures=exposures+1 where name='' and day=now() and site='R';
# at 713591
#030110 13:53:15 server id 7 Query thread_id=250476 exec_time=2
use dshield;
LOAD DATA INFILE '/home/dshield/feeds/country_details2003-01-06.txt' INTO TABLE country_list FIELDS TERMINATED BY ',' ESCAPED BY '\\' LINES TERMINATED BY '\n' (date,country,region,port,count);
# at 713735
#030110 13:53:21 server id 7 Query thread_id=264990 exec_time=0
error_code=0
use content;
SET TIMESTAMP=1042224801;
update banner_stats set exposures=exposures+1 where name='' and day=now() and site='R';
# at 713853
#030110 13:53:23 server id 7 Query thread_id=264992 exec_time=0
error_code=0

-------------- last lines from the relay-bin log -----------------------

#030110 13:53:03 server id 7 log_pos 712902 Query thread_id=264966
exec_time=0 error_code=0
SET TIMESTAMP=1042224783;
update banner_stats set exposures=exposures+1 where name='' and day=now() and site='R';
# at 748771
#030110 13:53:03 server id 7 log_pos 713020 Query thread_id=264967
exec_time=0 error_code=0
SET TIMESTAMP=1042224783;
update banner_stats set exposures=exposures+1 where name='' and day=now() and site='R';
# at 748895
#030110 13:53:05 server id 7 log_pos 713138 Query thread_id=264971
exec_time=0 error_code=0
SET TIMESTAMP=1042224785;
update banner_stats set exposures=exposures+1 where name='' and day=now() and site='R';
# at 749019
#030110 13:53:09 server id 7 log_pos 713256 Query thread_id=264981
exec_time=0 error_code=0
SET TIMESTAMP=1042224789;
update banner_stats set clicks=clicks+1 where name='' and day=now();
# at 749124
#030110 13:53:12 server id 7 log_pos 713355 Query thread_id=264983
exec_time=0 error_code=0
SET TIMESTAMP=1042224792;
update banner_stats set exposures=exposures+1 where name='' and day=now() and site='R';
# at 749248
#030110 13:53:12 server id 7 log_pos 713473 Query thread_id=264984
exec_time=0 error_code=0
SET TIMESTAMP=1042224792;
update banner_stats set exposures=exposures+1 where name='' and day=now() and site='R';

-------------- error log -------------

030110 10:53:20 mysqld started
030110 10:53:20 InnoDB: Started
/usr/sbin/mysqld: ready for connections
030110 10:53:20 Slave I/O thread: connected to master 'repl@xxxx:3306', replication started in log 'FIRST' at position 4
ERROR: 1146 Table 'aaaaa.reports' doesn't exist
030110 12:25:00 Slave: error 'Table 'aaaaa.reports' doesn't exist' on query 'CREATE TABLE temp_recent_reports SELECT targetport, protocol, date, sum(count) c, count(distinct target) targets, count(distinct source) sources FROM reports WHERE targetport IS NOT NULL and TARGETPORT!='0' and PROTOCOL!='1' and date > subdate(now(),interval 5 day ) GROUP by targetport, date, protocol', error_code=1146030110 12:25:00 Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'aa44-bin.001' position 316502
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=209715200
read_buffer_size=209711104
sort_buffer_size=209715192
max_used_connections=1
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3415663 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x87cd4f0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbfe5f2b8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x807328a
0x82834b8
0x80b36ce
0x80b408e
0x80ecaa1
0x80edb61
0x8280c6c
0x82b620a
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=92

Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 92 did to cause the crash. In some cases of really
bad corruption, the values shown above may be invalid.

The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
030110 13:53:19 mysqld restarted
030110 13:53:20 Can't start server: Bind on TCP/IP port: Address already in use030110 13:53:20 Do you already have another mysqld server running on port: 3306 ?
030110 13:53:20 Aborting

030110 13:53:20 /usr/sbin/mysqld: Shutdown Complete

030110 13:53:20 mysqld ended

On Fri, 10 Jan 2003 17:03:43 +0100
Guilhem Bichot wrote:

> > > > Log_event::read_log_event(): 'Event too big',
> > > > data_len=909189176,event_type=74 030109 2:30:13 Error in
> > > > Log_event::read_log_event(): 'Event too big',
> > > > data_len=1279610450,event_type=50
>
> 127961045 > 526MB and event types 74 and 50 do not exist.
> This shows that your slave was very probably reading data at a wrong position
> in the master's binlog.
> Probably this is some bug with the handling of LOAD DATA INFILE statements
> from a _3.23_ master by a _4.0_ slave. Probably a mismatch between the format
> of the LOAD in the master's binlog and the format expected by the slave.
> I will inspect this.
>
> > > These 'Event too big' entries are worrying : your slave was not able to
> > > read (and execute) some instructions (called events) from the master's
> > > binlog, hence he probably became out of sync with the master from that
> > > moment. What is the instruction which caused these messages ? Was it a
> > > LOAD DATA INFILE ? If it was a LOAD DATA INFILE, then :
> > > - what is the type of the table you loaded in (MyISAM, InnoDB,...)
> >
> > MyISAM
> >
> > > - If it was transactionnal (InnoDB, BDB), was the LOAD inside a
> > > transaction (BEGIN, LOAD, COMMIT
> > > or
> > > SET AUTOCOMMIT=0, LOAD) or not ?
> >
> > was non transactional
> >
> > > - What is the value of max_allowed_packet on your slave
> > > (show variables like 'max_allowed_packet') ?
> >
> > slave: 10484736 (mysql 4.0.8)
> > master: 10484736 (mysql 3.23.53a-Max)
> >
> > > - Do your master's binlogs have a size of approximately 1G ?
> >
> > no. largest one is 526 MByte, the one that was running as the
> > crash occured is now at 119M and was probably quite a bit
> > smaller (50MByte?) at the time of the crash
> >
> > BTW: The table I did try to transfer is now at 5Gig, was probably
> > around 4Gig as I did the transfer.
> >
> > > > > > Content of relay-log-info
> > > > > > -------------
> > > > > > 11654531
> > > > > > x440-bin.003
> > > > > > 96291803
> > > > > >
> > > > > > ------
> > > > > >
> > > > > > instruction #11654531 from relay-bin log:
> > > > > >
> > > > > > # at 11650620
> > > > > > #030109 2:36:44 server id 7 log_pos 96287892
> > > > > > #Append_block: file_id: 1 block_len: 3888
> > > > > > # at 11654531
> > > > > > #030109 2:36:44 server id 7 log_pos 96287892
> > > > > > #Exec_load: file_id=1
> > >
> > > I can't figure out the instruction that caused the above Append_block and
> > > Exec_load. I mean I have tested your sequence with a 3.23.54 master and
> > > 4.0.9 slave, and I never got such instructions in the relay-log (LOAD
> > > TABLE FROM MASTER is not logged in the master's binlog or in the slave's
> > > relay log). What caused these Append_block and Exec_load ? Is it some
> > > LOAD DATA INFILE ??
> >
> > A 'LOAD DATA INFILE' was executed on the master. maybe this is a record of
> > the replicated event? This 'LOAD DATA INFILE' imports an approx
> > 100MByte-1+Gig file into the 'reports' table.
>
> I need to understand if this LOAD DATA INFILE was done near the failing
> INSERT INTO oldreports SELECT * FROM reports where
> date > Was it :
> INSERT INTO oldreports SELECT * FROM reports ... ->FAILS,
> LOAD TABLE FROM MASTER,
> and _immediately_after_,
> LOAD DATA INFILE
>
> ?
>
>
> --
> For technical support contracts, visit https://order.mysql.com/?ref=mgbi
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Guilhem Bichot
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Software Developer
> /_/ /_/\_, /___/\___\_\___/ Bordeaux, France
> <___/ www.mysql.com +33 5 56 88 34 39
>

--
------------------------------------------------------------ --------
jullrich@euclidian.com Collaborative Intrusion Detection
join http://www.dshield.org

------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread13456@lists.mysql.com
To unsubscribe, e-mail