Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
On Mon, Feb 04, 2002 at 02:33:40PM -0700, Sasha Pachev wrote: > On Monday 04 February 2002 11:59 am, Jeremy Zawodny wrote: > > >?This does look like a libc bug. How did you build either one of the > binaries? > > > > They're your binaries. ?I don't buld my own binaries on Linux to save > > the hassle of using libraries that are different from what you folks > > use. :-) > > > > Strangely, it's working now--after a reboot. ?I'm gonna keep an eye on > > that machine. > > If it is working after reboot, I would name the disk cache > corruption as the primary suspect. My hypothesis is that you were > unlucky to have libnss.so cached in the buggy part of the disk > cache. Although our binaries are statically linked, on Linux calls > to name resolving functions allways require loading a shared > library, even if you are doing it from a statically linked binary. Could be. I sure hope that's not the case, but who knows at this point. > What kernel version are you running, and is this a virgin kernel > from kernel.org or a patched one from some Linux distribution? The box is currently running a 2.4.12 that I don't *think* is patched. I've gotta talk to the guy who builds our linux kernels and get an upgrade on that machine anyway. > P.S. "It works after reboot" is an ominous phrase that I hope will > be chased out of the Linux world quickly. Yeah, it really surprised me. > We need to track down this problem ASAP and send a full bug report > to the kernel developers. Agreed. Jeremy -- Jeremy D. Zawodny, <[EMAIL PROTECTED]> Technical Yahoo - Yahoo Finance Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936 MySQL 3.23.41-max: up 0 days, processed 22,591,842 queries (388/sec. avg) - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
On Monday 04 February 2002 11:59 am, Jeremy Zawodny wrote: > >?This does look like a libc bug. How did you build either one of the binaries? > > They're your binaries. ?I don't buld my own binaries on Linux to save > the hassle of using libraries that are different from what you folks > use. :-) > > Strangely, it's working now--after a reboot. ?I'm gonna keep an eye on > that machine. If it is working after reboot, I would name the disk cache corruption as the primary suspect. My hypothesis is that you were unlucky to have libnss.so cached in the buggy part of the disk cache. Although our binaries are statically linked, on Linux calls to name resolving functions allways require loading a shared library, even if you are doing it from a statically linked binary. What kernel version are you running, and is this a virgin kernel from kernel.org or a patched one from some Linux distribution? P.S. "It works after reboot" is an ominous phrase that I hope will be chased out of the Linux world quickly. We need to track down this problem ASAP and send a full bug report to the kernel developers. -- MySQL Development Team For technical support contracts, visit https://order.mysql.com/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA <___/ - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
On Mon, Feb 04, 2002 at 10:08:37AM -0700, Sasha Pachev wrote: > On Monday 04 February 2002 02:30 am, Jeremy Zawodny wrote: > > 0x807bb5f handle_segfault__Fi + 383 > > 0x82a94aa pthread_sighandler + 154 > > 0x7cb80076 __evoke_link_warning_llseek + 1954074198 > > 0x7cb7fe19 __evoke_link_warning_llseek + 1954073593 > > 0x7cb713e6 __evoke_link_warning_llseek + 1954013638 > > 0x7c97db8b __evoke_link_warning_llseek + 1951967595 > > 0x7c980668 __evoke_link_warning_llseek + 1951978568 > > 0x7c981200 __evoke_link_warning_llseek + 1951981536 > > 0x7c96dee4 __evoke_link_warning_llseek + 1951902916 > > 0x82ddd0a gethostbyaddr_r + 346 > > 0x82ddb44 gethostbyaddr + 196 > > 0x807ff98 ip_to_hostname__FP7in_addrPUi + 232 > > 0x808082c check_connections__FP3THD + 152 > > 0x8080c79 handle_one_connection__FPv + 321 > > This does look like a libc bug. How did you build either one of the binaries? They're your binaries. I don't buld my own binaries on Linux to save the hassle of using libraries that are different from what you folks use. :-) Strangely, it's working now--after a reboot. I'm gonna keep an eye on that machine. Jeremy -- Jeremy D. Zawodny, <[EMAIL PROTECTED]> Technical Yahoo - Yahoo Finance Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936 MySQL 3.23.41-max: up 0 days, processed 18,324,732 queries (409/sec. avg) - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
On Mon, Feb 04, 2002 at 07:15:33PM +0200, Sinisa Milivojevic wrote: > > Yes, this is troubling ... > > It could be hardware, though ... > > Can you find anything in MySQL log and especially in /var/log/dmesg > or /var/log/messages. Nope. > Sometimes, not often, Linux kernel is capable of noticing potential > hardware problems. > > If mysql server crashes after number of connections has increased, it > could be hardware, e.g. RAM or cache ... Yeah, it's hard to say. The machine has been stabe and running MySQL for a long time. I'll have to tinker some more and see. Jeremy -- Jeremy D. Zawodny, <[EMAIL PROTECTED]> Technical Yahoo - Yahoo Finance Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936 MySQL 3.23.41-max: up 0 days, processed 14,716,450 queries (376/sec. avg) - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
Jeremy Zawodny writes: > On Mon, Feb 04, 2002 at 02:27:01PM +0200, Sinisa Milivojevic wrote: > > That was your binary on Linux. > > Strangely, I just started up that exact same copy of 3.23.47-max and > it worked fine after a machine reboot. > > That's most unusual (and troubling). > > Thanks, > > Jeremy > -- > Jeremy D. Zawodny, <[EMAIL PROTECTED]> > Technical Yahoo - Yahoo Finance > Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936 > > MySQL 3.23.41-max: up 0 days, processed 13,981,507 queries (369/sec. avg) > Yes, this is troubling ... It could be hardware, though ... Can you find anything in MySQL log and especially in /var/log/dmesg or /var/log/messages. Sometimes, not often, Linux kernel is capable of noticing potential hardware problems. If mysql server crashes after number of connections has increased, it could be hardware, e.g. RAM or cache ... -- Regards, __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus <___/ www.mysql.com - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
On Monday 04 February 2002 02:30 am, Jeremy Zawodny wrote: > 0x807bb5f handle_segfault__Fi + 383 > 0x82a94aa pthread_sighandler + 154 > 0x7cb80076 __evoke_link_warning_llseek + 1954074198 > 0x7cb7fe19 __evoke_link_warning_llseek + 1954073593 > 0x7cb713e6 __evoke_link_warning_llseek + 1954013638 > 0x7c97db8b __evoke_link_warning_llseek + 1951967595 > 0x7c980668 __evoke_link_warning_llseek + 1951978568 > 0x7c981200 __evoke_link_warning_llseek + 1951981536 > 0x7c96dee4 __evoke_link_warning_llseek + 1951902916 > 0x82ddd0a gethostbyaddr_r + 346 > 0x82ddb44 gethostbyaddr + 196 > 0x807ff98 ip_to_hostname__FP7in_addrPUi + 232 > 0x808082c check_connections__FP3THD + 152 > 0x8080c79 handle_one_connection__FPv + 321 This does look like a libc bug. How did you build either one of the binaries? -- MySQL Development Team For technical support contracts, visit https://order.mysql.com/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA <___/ - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
On Mon, Feb 04, 2002 at 02:27:01PM +0200, Sinisa Milivojevic wrote: > > Jeremy, > > It could also be a bug in glibc. > > As you are using Linux, can you try out binary ?? That was your binary on Linux. Strangely, I just started up that exact same copy of 3.23.47-max and it worked fine after a machine reboot. That's most unusual (and troubling). Thanks, Jeremy -- Jeremy D. Zawodny, <[EMAIL PROTECTED]> Technical Yahoo - Yahoo Finance Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936 MySQL 3.23.41-max: up 0 days, processed 13,981,507 queries (369/sec. avg) - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
Hi, > To tell you a truth, I have downloaded 2.2.5 but still have not found > time to build / install them. Perhaps the fear of glibc compilation / installation ;) I've already installed 2.2.5, and it works really fine for me (and at least it compiles with gcc 3.0.3 ! :)) (with #define STACK_SIZE (128 * 1024) and #define PTHREAD_THREADS_MAX 4096) Anyway, thank you for the advice :) Regards, Jocelyn Fournier - Original Message - From: "Sinisa Milivojevic" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, February 04, 2002 1:49 PM Subject: Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB) > jocelyn fournier writes: > > Hi, > > > > About glibc, I saw the 2.2.5 release included the spinlock.c patch, part of > > the internals.h (except the following part : > > -#define STACK_SIZE (2 * 1024 * 1024) > > +#define STACK_SIZE (128 * 1024) > > ) > > The local_lim.h is also partially patched : > > > > The following part : > > -#define PTHREAD_THREADS_MAX 1024 > > +#define PTHREAD_THREADS_MAX 4096 > > > > is missing. > > > > So my question is : with glibc 2.2.5, should I modify the STACK_SIZE and > > PTHREAD_THREADS_MAX values ? (and why didn't they applied those part of > > patches ?) > > > > Thank you ! > > > > Best Regards, > > > > Jocelyn Fournier > > Presence-PC > > > To tell you a truth, I have downloaded 2.2.5 but still have not found > time to build / install them. > > For MySQL 64 * 1024 stack size is sufficient and should be set in > that fashion if you run lot's of connections. Similar reasoning > applies to number of threads. > > -- > Regards, >__ ___ ___ __ > / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic <[EMAIL PROTECTED]> > / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer > /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus ><___/ www.mysql.com > > - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
jocelyn fournier writes: > Hi, > > About glibc, I saw the 2.2.5 release included the spinlock.c patch, part of > the internals.h (except the following part : > -#define STACK_SIZE (2 * 1024 * 1024) > +#define STACK_SIZE (128 * 1024) > ) > The local_lim.h is also partially patched : > > The following part : > -#define PTHREAD_THREADS_MAX 1024 > +#define PTHREAD_THREADS_MAX 4096 > > is missing. > > So my question is : with glibc 2.2.5, should I modify the STACK_SIZE and > PTHREAD_THREADS_MAX values ? (and why didn't they applied those part of > patches ?) > > Thank you ! > > Best Regards, > > Jocelyn Fournier > Presence-PC To tell you a truth, I have downloaded 2.2.5 but still have not found time to build / install them. For MySQL 64 * 1024 stack size is sufficient and should be set in that fashion if you run lot's of connections. Similar reasoning applies to number of threads. -- Regards, __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus <___/ www.mysql.com - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
Hi, About glibc, I saw the 2.2.5 release included the spinlock.c patch, part of the internals.h (except the following part : -#define STACK_SIZE (2 * 1024 * 1024) +#define STACK_SIZE (128 * 1024) ) The local_lim.h is also partially patched : The following part : -#define PTHREAD_THREADS_MAX1024 +#define PTHREAD_THREADS_MAX4096 is missing. So my question is : with glibc 2.2.5, should I modify the STACK_SIZE and PTHREAD_THREADS_MAX values ? (and why didn't they applied those part of patches ?) Thank you ! Best Regards, Jocelyn Fournier Presence-PC - Original Message - From: "Sinisa Milivojevic" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, February 04, 2002 1:27 PM Subject: Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB) > Jeremy Zawodny writes: > > I just attempted to upgrade a 3.23.41-max server on Linux 2.4.12 to > > 3.23.47-max. Before starting up 3.23.47-max, I added several Innodb > > options to the my.cnf file: > > > [skip] > > > > Thanks, > > > > Jeremy > > -- > > Jeremy D. Zawodny, <[EMAIL PROTECTED]> > > Technical Yahoo - Yahoo Finance > > Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936 > > > > MySQL 3.23.41-max: up 0 days, processed 4,634,010 queries (446/sec. avg) > > > > Jeremy, > > It could also be a bug in glibc. > > As you are using Linux, can you try out binary ?? > > > -- > Regards, >__ ___ ___ __ > / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic <[EMAIL PROTECTED]> > / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer > /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus ><___/ www.mysql.com > > > - > 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 <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > > - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
Hi! InnoDB seems to have created the database and started ok. This does not look like an InnoDB bug. I think gethostbyaddr asks from a connection the hostname, and subsequent code checks that the host has access rights to mysqld. For some reason gethostbyaddr_r crashes. Hmm.. if you could run inside gdb and look what parameters mysqld passes to gethostbyaddr in mysql/sql/hostname.cc, then it would be easier to determine what goes wrong. Regards, Heikki Innobase Oy Jeremy Zawodny wrote in message ... >I just attempted to upgrade a 3.23.41-max server on Linux 2.4.12 to >3.23.47-max. Before starting up 3.23.47-max, I added several Innodb >options to the my.cnf file: > >---snip--- >innodb_data_file_path = ibdata1:2000M;ibdata2:2000M;ibdata3:2000M;ibdata4:2000M >innodb_data_home_dir = /home/mysql/yahoo/ibdata >innodb_log_group_home_dir = /home/mysql/yahoo/iblog >innodb_log_arch_dir = /home/mysql/yahoo/iblog >set-variable = innodb_mirrored_log_groups=1 >set-variable = innodb_log_files_in_group=3 >set-variable = innodb_log_file_size=128M >set-variable = innodb_log_buffer_size=32M >innodb_flush_log_at_trx_commit=0 >innodb_log_archive=0 >set-variable = innodb_buffer_pool_size=384M >set-variable = innodb_additional_mem_pool_size=4M >set-variable = innodb_file_io_threads=4 >set-variable = innodb_lock_wait_timeout=50 >---snip--- > >And then started the server. It created the 4 data files as well as >the the log files. Then I got: > >InnoDB: Doublewrite buffer not found: creating new >InnoDB: Doublewrite buffer created >InnoDB: Creating foreign key constraint system tables >InnoDB: Foreign key constraint system tables created >020204 1:24:13 InnoDB: Started >/home/mysql/bin/mysqld: ready for connections >mysqld got signal 11; > >and a stack trace, which resolved into: > >0x807bb5f handle_segfault__Fi + 383 >0x82a94aa pthread_sighandler + 154 >0x7cb80076 __evoke_link_warning_llseek + 1954074198 >0x7cb7fe19 __evoke_link_warning_llseek + 1954073593 >0x7cb713e6 __evoke_link_warning_llseek + 1954013638 >0x7c97db8b __evoke_link_warning_llseek + 1951967595 >0x7c980668 __evoke_link_warning_llseek + 1951978568 >0x7c981200 __evoke_link_warning_llseek + 1951981536 >0x7c96dee4 __evoke_link_warning_llseek + 1951902916 >0x82ddd0a gethostbyaddr_r + 346 >0x82ddb44 gethostbyaddr + 196 >0x807ff98 ip_to_hostname__FP7in_addrPUi + 232 >0x808082c check_connections__FP3THD + 152 >0x8080c79 handle_one_connection__FPv + 321 > >I'm going back to 3.23.41-max for now. > >Any idea what's up? The configuration, other than InnoDB was >virtually identical to the previous version. In fact, I copied the >working my.cnf file and added the innodb bits. > >Thanks, > >Jeremy >-- >Jeremy D. Zawodny, <[EMAIL PROTECTED]> >Technical Yahoo - Yahoo Finance >Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936 > >MySQL 3.23.41-max: up 0 days, processed 4,634,010 queries (446/sec. avg) > - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
mysqld crash & stack trace from 3.23.47-max (with InnoDB)
I just attempted to upgrade a 3.23.41-max server on Linux 2.4.12 to 3.23.47-max. Before starting up 3.23.47-max, I added several Innodb options to the my.cnf file: ---snip--- innodb_data_file_path = ibdata1:2000M;ibdata2:2000M;ibdata3:2000M;ibdata4:2000M innodb_data_home_dir = /home/mysql/yahoo/ibdata innodb_log_group_home_dir = /home/mysql/yahoo/iblog innodb_log_arch_dir = /home/mysql/yahoo/iblog set-variable = innodb_mirrored_log_groups=1 set-variable = innodb_log_files_in_group=3 set-variable = innodb_log_file_size=128M set-variable = innodb_log_buffer_size=32M innodb_flush_log_at_trx_commit=0 innodb_log_archive=0 set-variable = innodb_buffer_pool_size=384M set-variable = innodb_additional_mem_pool_size=4M set-variable = innodb_file_io_threads=4 set-variable = innodb_lock_wait_timeout=50 ---snip--- And then started the server. It created the 4 data files as well as the the log files. Then I got: InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: Creating foreign key constraint system tables InnoDB: Foreign key constraint system tables created 020204 1:24:13 InnoDB: Started /home/mysql/bin/mysqld: ready for connections mysqld got signal 11; and a stack trace, which resolved into: 0x807bb5f handle_segfault__Fi + 383 0x82a94aa pthread_sighandler + 154 0x7cb80076 __evoke_link_warning_llseek + 1954074198 0x7cb7fe19 __evoke_link_warning_llseek + 1954073593 0x7cb713e6 __evoke_link_warning_llseek + 1954013638 0x7c97db8b __evoke_link_warning_llseek + 1951967595 0x7c980668 __evoke_link_warning_llseek + 1951978568 0x7c981200 __evoke_link_warning_llseek + 1951981536 0x7c96dee4 __evoke_link_warning_llseek + 1951902916 0x82ddd0a gethostbyaddr_r + 346 0x82ddb44 gethostbyaddr + 196 0x807ff98 ip_to_hostname__FP7in_addrPUi + 232 0x808082c check_connections__FP3THD + 152 0x8080c79 handle_one_connection__FPv + 321 I'm going back to 3.23.41-max for now. Any idea what's up? The configuration, other than InnoDB was virtually identical to the previous version. In fact, I copied the working my.cnf file and added the innodb bits. Thanks, Jeremy -- Jeremy D. Zawodny, <[EMAIL PROTECTED]> Technical Yahoo - Yahoo Finance Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936 MySQL 3.23.41-max: up 0 days, processed 4,634,010 queries (446/sec. avg) - 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
