into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.0-opt

into  kaamos.(none):/data/src/opt/mysql-5.0-opt

into  kaamos.(none):/data/src/opt/mysql-4.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  mysql.com:/home/hf/work/32801/my51-32801

into  mysql.com:/misc/mysql/34749/51-34749

into  mysql.com:/misc/mysql/34749/50-34749

into  mysql.com:/misc/mysql/34749/51-34749

into  mysql.com:/misc/mysql/29645/51-29645

into  mysql.com:/misc/mysql/29645/50-29645

into  mysql.com:/misc/mysql/29645/51-29645

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.0-opt

into  kaamos.(none):/data/src/opt/bug34889/my51

into  magare.gmz:/home/kgeorge/mysql/work/B34909-5.1-opt

into  magare.gmz:/home/kgeorge/mysql/autopush/B34909-5.0-opt

  --master-data

No error code was returned by mysqldump if it detects that binary
logging is not enabled on the server.
Fixed by returning error code.

into  mysql.com:/home/psergey/mysql-5.0-bug34945

                    sporadically

Under some circumstances, the mysql_insert_id() value after SELECT ...
INSERT could return a wrong value. This could happen when the last
SELECT ... INSERT did not involve an AUTO_INCREMENT column, but the
value of mysql_insert_id() was changed by some previous statements.

Fixed by checking the value of thd->insert_id_used in
select_insert::send_eof() and returning 0 for mysql_insert_id() if it
is not set.

into  trift2.:/MySQL/M51/mysql-5.1

- Apply Eric Bergen's patch: in join_read_always_key(), move ha_index_init() call
  to before the late NULLs filtering code.
- Backport function comments from 6.0.

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  kaamos.(none):/data/src/opt/mysql-5.0-opt

into  kaamos.(none):/data/src/opt/bug31781/my51

                    with errno 17

my_create() did not perform any checks for the case when a file is
successfully created by a call to open(), but the call to
my_register_filename() later fails because the number of open files
has exceeded the my_open_files limit. This can happen on platforms 
which do not have getrlimit(), and hence we do not know the real limit
for open files. In such a case an error was returned to a caller
although the file has actually been created. Since callers assume
my_create() to return an error only when it failed to create a file,
they did not perform any cleanups, leaving an 'orphaned' file on the
file system.

Fixed by adding a check for the above case to my_create() and ensuring
the newly created file is deleted before returning an error.

Creating a deterministic test case in the test suite is impossible,
because the exact steps required to reproduce the above situation
depend on the platform and/or environment (OS per-user limits, queries
executed by previous tests, startup parameters). The patch was
manually tested on Windows using examples posted in the bug report.

into  mysql.com:/home/gluh/MySQL/mysql-5.1-opt

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt

wait_timeout test enabled

into  host.loc:/home/uchum/work/5.0-opt