bk commit into 5.0 tree (guilhem:1.1939)

[guilhem]

Below is the list of changes that have just been committed into a local
5.0 repository of guilhem. When guilhem does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html

ChangeSet
  1.1939 05/09/08 22:18:29 guilhem@stripped +1 -0
  WL#1012: saving in wl1012-review-pending-comments.txt
  information obtained from Mats and TomasU, for reference (I'll rewrite
  this info in another way when I understand it fully).

  wl1012-review-pending-comments.txt
    1.2 05/09/08 22:17:08 guilhem@stripped +24 -3
    saving information obtained from Mats and TomasU, for reference

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	guilhem
# Host:	gbichot2.local
# Root:	/home/mysql_src/mysql-5.0-wl1012

--- 1.1/wl1012-review-pending-comments.txt	2005-09-08 18:21:59 +02:00
+++ 1.2/wl1012-review-pending-comments.txt	2005-09-08 22:17:08 +02:00
@@ -574,13 +574,34 @@
 [G2TODO] I had missed a "==" somewhere, so it's not useless. Still I
 [G2TODO] failed to understand how it works. Could you please write a
 [G2TODO] comment somewhere to explain (there are 3 table_map_version:
-[G2TODO] one in MYSQL_LOG, one in THD, one in TABLE...) ?
+[G2TODO] one in MYSQL_LOG, one in THD, one in TABLE...) ? Here is an
+[G2TODO] explanation from TomasU:
+
+[G2TODO] <tomas> guilhem, as rbr is implemented each transaction in the binlog
+[G2TODO] needs a table map for each table used in the trans.
+[G2TODO] <tomas> m_table_map_version is used to keep track of if the table has
+[G2TODO] been mapped or not.
+[G2TODO] <tomas> each "transaction" in the binlog has a table_map_version.
+[G2TODO] <tomas> if m_table_map_version == table_map_version(binlog)  then the
+[G2TODO] table has been mapped, otrherwise not.
+
+[G2TODO] <tomas> guilhem, I think the worst that can happen is that a table
+[G2TODO] becomes mapped several times... which doesn't matter... but it should
+[G2TODO] be fixed, yes.  When it was put there originally, we were only running
+[G2TODO] cluster replication... and then there is a lock on the binlog
+[G2TODO] throughout a transaction... so there is no thread issue there.
 
 [G2TODO] THD::m_table_map_version is just a pointer to
 [G2TODO] mysql_bin_log.m_table_map_version, so it burns 4 or 8 bytes
 [G2TODO] per thread for "nothing". I removed it. The questions above remain.
 
-[G2TODO] check Mats' answers
+[G2TODO] re-read Tomas' answer and see if problems exist
+[G2TODO] (thread-safety etc). Mats has written:
+[G2TODO] "To me, the code seems to assume that there is only one table mapped
+[G2TODO] at each instant, which is wrong".
+[G2TODO] About table mappings, here is also a comment from Mats:
+[G2TODO] "Table mappings live until the end of the transaction, which is the
+[G2TODO] end of statement if autocommit is on."
 
 > +   description_event_for_exec(0), description_event_for_queue(0)
 >  {
@@ -1274,7 +1295,7 @@
 
 [G] what about HA_ERR_FOUND_DUPP_UNIQUE?
 
-[G2TODO]
+[G2TODO] Mats says all DUPP should be handled the same.
 
 > +      case HA_ERR_RECORD_CHANGED:
 > +	/* Idempotency support: OK if tuple does not exist */