Peter,
could you ftp your binary (compiled with -g option) to
support.mysql.com directory /pub/mysql/Incoming
I can then try to run the ATIS test on your binary on our SMP Linux.
One possible reason for the errors you get is that your version
of GCC is buggy in inlining of code, but that is only a wild guess.
Regards,
Heikki
At 12:40 PM 3/15/01 +0300, you wrote:
>Hello Heikki,
>
> Finally I was able to check the innobase tables included into mysql
> 3.23.34. Well first several times I was quite happy about them, but
> later understud that this is because option --create-options is
> broken :)
>
> So now I must say On my system innobase seems to work as bad as it
> worked before :(
>
> - ATIS test fails.
>Retrieving data
>Warning: Query 'select city.city_name,state.state_name,city.city_code from
state,city where city.state_code=state.state_code' return
>ed 1 rows when it should have returned 11 rows
>Got error: when executing select flight.flight_code,aircraft.aircraft_type
from flight,aircraft where flight.aircraft_code=aircraft
>.aircraft_code
>got 0 instead of 579 ***
>
> - mysqld is restarted during alter table test and one more time
> during the tests:
>
>Innobase: Started
>/usr/local/mysql/libexec/mysqld: ready for connections
>Innobase: Warning: out of memory in additional memory pool.
>Innobase: Innobase will start allocating memory from the OS.
>Innobase: You should restart the database with a bigger value in
>Innobase: the MySQL .cnf file for innobase_additional_mem_pool_size.
>010314 19:00:00 Warning: Checking table: './oldgoodcounter/stop_recs'
>010314 19:00:01 Warning: Checking table:
'./oldgoodcounter/registrants_stats'
>mysqld got signal 11;
>The manual section 'Debugging a MySQL server' tells you how to use a
>stack trace and/or the core file to produce a readable backtrace that may
>help in finding out why mysqld died.
>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...
>Bogus stack limit or frame pointer, aborting backtrace.
>Thread 5126 stopped in file buf0lru.c line 371
>Thread 5126 stopped in file buf0lru.c line 371
>
>Number of processes running now: 0
>010314 21:13:33 mysqld restarted
>Innobase: Database was not shut down normally.
>Innobase: Starting recovery from log files...
>Innobase: Starting log scan based on checkpoint at
>Innobase: log sequence number 0 3385030377
>
> - It seems like error message for error 139 should be changed because
> it says about 16M there innobase and gemini has their own limits
> about it.
> 139 = Too big row (>= 16 M)
>
>
>Now few words about reasons why this may happen (I'll try to check
>them out soon)
>
>1) I'm using 2.4.2 kernel,SMP - so there may be some incompatibilities.
>2) I'm usung patched for 2GB limit GLIBC
>3) I'm using ReiserFS file system.
>4) The parameters I'm using. (Like bdb does not work with big
>tablecache)
>
>Anyway MYSQL with MYISAM works with no problem on this system, and I
>use the same system for production on 20 machines so this looks for me
>more like incomportability problem.
>
>
>
>
>--
>Best regards,
> Peter mailto:[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
