into  magare.gmz:/home/kgeorge/mysql/autopush/B28284-5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

  Additional fix for the bug#30245.

into  a88-113-38-195.elisa-laajakaista.fi:/home/my/bk/mysql-5.1-marvel

into  a88-113-38-195.elisa-laajakaista.fi:/home/my/bk/mysql-5.1-marvel

into  a88-113-38-195.elisa-laajakaista.fi:/home/my/bk/mysql-5.0-marvel

into  moonbone.local:/mnt/gentoo64/work/30245-bug-5.0-opt-mysql

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

into  trift2.:/MySQL/M50/push-5.0

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

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

1) Ensure "init_db.sql" and "test_db-sql" really get built.

2) Ensure the "*.def" files with NetWare linker options get distributed to the proper directories.

When locking a "fast" mutex a static variable cpu_count 
was used as a flag to initialize itself on the first usage 
by calling sysconf() and setting non-zero value.
This is not thread and optimization safe on some 
platforms. That's why the global initialization needs 
to be done once in a designated function.
This will also speed up the usage (by a small bit) 
because it won't have to check if it's initialized on
every call.

Fixed by moving the fast mutexes initialization out of 
my_pthread_fastmutex_lock() to fastmutex_global_init()
and call it from my_init()

into  a88-113-38-195.elisa-laajakaista.fi:/home/my/bk/mysql-5.1-marvel

into  a88-113-38-195.elisa-laajakaista.fi:/home/my/bk/mysql-5.1-marvel

into  a88-113-38-195.elisa-laajakaista.fi:/home/my/bk/mysql-5.0-marvel

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

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

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

into  trift2.:/MySQL/M50/push-5.0

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

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

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

into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/pushed/netware-5.1

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

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

into  bk-internal.mysql.com:/data0/bk/mysql-5.1-opt

into  bk-internal.mysql.com:/users/gshchepa/mysql-5.1-opt

into  bk-internal.mysql.com:/users/gshchepa/mysql-5.0-opt

In the ha_partition::position() we didn't calculate the number
of the partition of the record. We used m_last_part value instead,
relying on that it is set in other place like previous call of a method
like ::write_row(). In replication we don't call any of these befor
position(). Delete_rows_log_event::do_exec_row calls find_and_fetch_row.
In case of InnoDB-based PARTITION table, we have HA_PRIMARY_KEY_REQUIRED_FOR_POSITION
enabled, so use position() / rnd_pos() calls to fetch the record.

Fixed by adding partition_id calculation to the ha_partition::position()