RE: Red Hat 8.0 compile problems with 4.0.10
Hello, I just tried compiling and using MySQL-4.0.11 (from the BitKeeper repository) on RedHat 8.0, and this problem seems to have gone away: Unfortunately the problem is still occurring even after retrieving the latest source from the repository (I used the compile_pentium_debug script). Can you repeat the problem using 4.0.10? It seems to happen every time, and on any installation of Red Hat 8.0 I have. Mark - I note that you have been able to successfully compile and run a source distribution of MySQL 4.0.10 on Red Hat 8.0. Was your installation of Red Hat customised in any way? What was the configure line for MySQL? Of course Red Hat 7.3 will work but unfortunately the server in question requires additional drivers which are only available in Red Hat 8.0. It seems that the thread stack is set to 192K by default in 4.0.10. Correct, but increasing even beyond the recommended 192K still results in the same error. I'm not really sure what I'm supposed to be looking for - are there any further tests that I can run that would be of any use? Regards, Duncan Maitland. - 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
Red Hat 8.0 compile problems with 4.0.10
I am having trouble compiling a custom mysqld (version 4.0.10) under Red Hat 8.0 - I did email this list a few weeks ago and I have tried a few things since then but I am asking again in the hope that someone more knowledgeable might be able to help. As far as I can tell this is a compiling or linking problem. System information: The system is a dual AMD Athlon MP 1800+ on a Tyan S2466 mainboard with 1GB ram and 1GB swap. The system is using an Adaptec 2400A ATA RAID card. Operating system: Standard installation of Red Hat Linux 8.0 - kernel is 2.4.18-14smp My configure line: ./configure --prefix=/usr/local/mysql-4.0.10 --localstatedir=/home/database/mysql-4.0.10 --enable-assembler --disable-shared --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static --enable-thread-safe-client --with-extra-charsets=complex --with-debug --with-tcp-port=3307 --with-unix-socket-path=/tmp/mysql-4.0.10.sock The problem surfaces when the mysql_install_db script attempts to install the prepared grant tables. Output is as follows: [root@jupiter mysql-4.0.10-gamma]# ./scripts/mysql_install_db --defaults-file=/etc/mysql/mysql-4.0.10.cnf Preparing db table Preparing host table Preparing user table Preparing func table Preparing tables_priv table Preparing columns_priv table Installing all prepared tables 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=268435456 read_buffer_size=1044480 sort_buffer_size=1048568 max_used_connections=0 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 = 466543 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x83e3718 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=0xbf5fefb8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8089d51 0x823f280 0x825dc8d 0x822fe03 0x80ab6de 0x8095113 0x823a6d5 0x827669a ./scripts/mysql_install_db: line 1: 18414 Segmentation fault /usr/local/mysql-4.0.10/libexec/mysqld --defaults-file=/etc/mysql/mysql-4.0.10.cnf --log --debug --bootstrap --skip-grant-tables --basedir=/usr/local/mysql-4.0.10 --datadir=/home/database/mysql-4.0.10 --skip-innodb --skip-bdb Installation of grant tables failed! Examine the logs in /home/database/mysql-4.0.10 for more information. You can also try to start the mysqld daemon with: /usr/local/mysql-4.0.10/libexec/mysqld --skip-grant You can use the command line tool /usr/local/mysql-4.0.10/bin/mysql to connect to the mysql database and look at the grant tables: shell /usr/local/mysql-4.0.10/bin/mysql -u root mysql mysql show tables Try 'mysqld --help' if you have problems with paths. Using --log gives you a log in /home/database/mysql-4.0.10 that may be helpful. The latest information about MySQL is available on the web at http://www.mysql.com Please consult the MySQL manual section: 'Problems running mysql_install_db', and the manual section that describes problems on your OS. Another information source is the MySQL email archive. Please check all of the above before mailing us! And if you do mail us, you MUST use the /usr/local/mysql-4.0.10/bin/mysqlbug script! [root@jupiter mysql-4.0.10-gamma]# The stack trace resolved as follows: 0x8089d51 handle_segfault + 431 0x823f280 __pthread_sighandler + 116 0x825dc8d vfprintf + 8057 0x822fe03 _db_doprnt_ + 189 0x80ab6de _Z19close_thread_tablesP3THDb + 290 0x8095113 handle_bootstrap + 779 0x823a6d5 pthread_start_thread + 177 0x827669a thread_start + 4 If anyone has any ideas, or even better, if anyone has a solution to this problem then please reply to this post. Many thanks, Duncan Maitland [EMAIL PROTECTED] - 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
Red Hat 8.0 problems installing from source
I am installing MySQL 4.0.9 on a server running Red Hat 8.0 but am running into some showstoppers. I seem to have success compiling - no warnings are raised - but mysql_install_db will crash when installing the grant tables. Initially I thought it may have been the hardware configuration (I have had some hardware and driver issues) however testing on other systems of different configurations end in the same result. Installing the binary distribution will work fine, but unfortunately I need to modify the stopword list in ft_static.c Is anyone else experiencing these problems under Red Hat 8.0? I notice from mailing lists there are some known issues but these seem to be of a different nature to the ones I am experiencing. Here is my configure line: ./configure --prefix=/usr/local/mysql --localstatedir=/home/database/mysql --enable-assembler --disable-shared --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static --enable-thread-safe-client Here is the output from mysql_install_db: # ./scripts/mysql_install_db Preparing db table Preparing host table Preparing user table Preparing func table Preparing tables_priv table Preparing columns_priv table Installing all prepared tables 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 sort_buffer_size=2097144 max_used_connections=0 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 = 225791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x83b1720 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=0xbf5fea88, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8088860 0x822b9b8 0x8242336 0x80980fd 0x809adde 0x8097f1c 0x80929c0 0x8226e0d 0x82629da ./scripts/mysql_install_db: line 1: 24876 Segmentation fault /usr/local/mysql/libexec/mysqld --bootstrap --skip-grant-tables --basedir=/usr/local/mysql --datadir=/home/database/mysql --skip-innodb --skip-bdb Installation of grant tables failed! Here is some additional information from mysqlbug: Release:mysql-4.0.9-gamma (Source distribution) C compiler: gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) C++ compiler: g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) System: Linux minime 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux Architecture: i686 Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc /usr/bin/cc GCC: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit Thread model: posix gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) Compilation info: CC='gcc' CFLAGS='' CXX='g++' CXXFLAGS='' LDFLAGS='' ASFLAGS='' LIBC: lrwxrwxrwx1 root root 14 Jan 25 17:36 /lib/libc.so.6 - libc-2.2.93.so -rwxr-xr-x1 root root 1235468 Sep 5 23:12 /lib/libc-2.2.93.so -rw-r--r--1 root root 2233342 Sep 5 22:59 /usr/lib/libc.a -rw-r--r--1 root root 178 Sep 5 22:50 /usr/lib/libc.so Configure command: ./configure '--prefix=/usr/local/mysql' '--localstatedir=/home/database/mysql' '--enable-assembler' '--disable-shared' '--with-mysqld-ldflags=-all-static' '--with-client-ldflags=-all-static' '--enable-thread-safe-client' I hope this information is helpful to anyone who might be willing to have a look into this. If there is any other assistance I can provide please let me know. Cheers, Duncan [EMAIL PROTECTED] - 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
FULLTEXT relevance and phrase searching
The MATCH syntax will return a number indicating the relevance of a
particular record to the specified criteria. I would like to generate
similar numbers for phrase searches... please read on.
I have written code which will generate an SQL query that allows phrase
searching (without using IN BOOLEAN MODE - I do not wish to use 4.0.1
alpha in production, it doesn't seem to rank documents well at all
anyway) but currently I only rank the results by the number of
occurrences of the phrase. This is an example of an SQL query for the
phrase phrase search:
SELECT id, title, (LENGTH(body) - LENGTH(REPLACE(LOWER(body),
LOWER('phrase search'),''))) / LENGTH('phrase search') AS relevance FROM
articles WHERE MATCH (body) AGAINST ('phrase search') AND
(LOCATE('phrase search', body)) ORDER BY relevance DESC
This might return something like this:
++-+---+
| id | title | relevance |
++-+---+
| 1 | Phrase searching with MySQL | 9.0 |
| 2 | MySQL Full-Text Search | 7.0 |
| 3 | Searching Web Sites | 2.0 |
++-+---+
This ranks documents in a reasonable way, but not as accurately as a
single word with the MATCH syntax. However when combining the phrase
search with a single word things become difficult.
From the MySQL documentation (for the MATCH syntax): Relevance is
computed based on the number of words in the row, the number of unique
words in that row, the total number of words in the collection, and the
number of documents (rows) that contain a particular word. How can I
apply a similar method to my phrase ranking?
My phrase ranking is only a whole number indicating the number of
occurrences. Simply adding the two together will not produce any usable
ranking. How can I best combine this number generated by MATCH for a
single word with my ranking for a phrase?
I suppose I could multiply my phrase ranking by the MATCH ranking of all
the words in that phrase, like this:
SELECT id, title, MATCH (body) AGAINST ('phrase search') * (LENGTH(body)
- LENGTH(REPLACE(LOWER(body), LOWER('phrase search'),''))) /
LENGTH('phrase search') AS relevance FROM ...
However, I'm not sure if this is the most accurate method.
Any other thoughts would be greatly appreciated!
Regards,
Duncan Maitland
[EMAIL PROTECTED]
-
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
FULLTEXT indexing / ACID transactions
I am writing an application which requires FULLTEXT indexing capability, and ACID transaction support would also be a plus. I am currently developing on MySQL 4.0.1. As I understand it, MyISAM tables support FULLTEXT indexing but do not support ACID transactions. Also, InnoDB tables support ACID transactions but do not support FULLTEXT indexing. Is this correct? Is there another table type I can use to enable both FULLTEXT indexing and ACID transactions or is there some sort of workaround? Also, as a side issue, is anyone able to compare the pros and cons of MyISAM / InnoDB (or is there a good online resource?) Many thanks, from Duncan Maitland [EMAIL PROTECTED] - 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
Multiple copies of messages
I am sorry for the off-the-topic question. I have been receiving random multiple copies of many (but not all) of the messages in this MySQL list - some four or five times. Some of them are copies of messages that were actually sent days previously. It is rather strange behaviour, so I just thought I'd check to see if everyone else has been receiving multiple copies as well. If so, then I can eliminate other possible sources of the problem. Thanks, from Duncan Maitland [EMAIL PROTECTED] - 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: No Database Encryption
It's only dangerous if a customer can trick your web frontend into displaying the output of SELECT * FROM USERS, for example. If the frontend only uses hardcoded queries, or quotes every user-supplied parameter, there's no problem. In fact, you need the password in plaintext to support a I forgot my password; email it to me feature. To explain further, MySQL account passwords are encrypted using the (one-way) password function. This works in a similar way to the UNIX passwd file so that people who do have access to the mysql.user table (possibly through a read-only backup account or whatever) can't (without a lot of effort) get any unencrypted passwords back, so they can't log in to the database as another user. You could use PASSWORD to encrypt passwords for user accounts in your database app if there is any chance that unauthorised people could access the table, otherwise it is not necessary. (Plus there is the issue of staff turnover mentioned earlier). As a side note, absolutely *all* user-supplied parameters should be verified. Sure, you can quote, but what if a user paramater includes something like abc; delete from customers; . The quote has been closed, and then the user can do anything he likes. You also need to scan the user input for special characters like and then escape them (\), something which PHP will do for you (if you have it configured that way). Cheers, from Duncan - 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
