Fix for bug 229.

Make sure that the set origin is caught up before opening the transaction used for adding multiple tables/sequences. If that transaction is opended against an origin that is behind slonik will not see the node catch up after the transaction has been opened.
machack666 · Aug 16, 2011 · 7a8aa60 · 7a8aa60
1 parent 6c7c140
commit 7a8aa60
Showing 1 changed file with 71 additions and 0 deletions.
diff --git a/src/slonik/slonik.c b/src/slonik/slonik.c
@@ -3707,6 +3707,42 @@ slonik_set_add_table(SlonikStmt_set_add_table * stmt)
 	if (adminfo1 == NULL)
 		return -1;
 
+	/**
+	 * make sure that the origin node is caught up with
+	 * the last event node *before* opening the transaciton
+	 * the 'set add table' will take place in.
+	 *
+	 * Once that transaction is opened and has a lock
+	 * on sl_config_lock the slon for the node  won't be 
+	 * able to process many event types from other nodes.  
+	 * So if the origin is behind it will not be able to catch up
+	 * until the transaction completes.
+	 *
+	 * The slonik_submitEvent(...) that submits the
+	 * setAddTable event might 'wait' until the
+	 * origin is caught up, so we make sure that the
+	 * origin is caught up before opening the
+	 * transaction.
+	 **/
+	if(db_begin_xact((SlonikStmt*)stmt,adminfo1,false) < 0)
+		return -1;
+	dstring_init(&query);	
+	slon_mkquery(&query,"lock table \"_%s\".sl_event_lock;"
+					"select \"_%s\".createEvent('_%s', 'SYNC'); ",
+					stmt->hdr.script->clustername,
+					stmt->hdr.script->clustername,
+					stmt->hdr.script->clustername);
+	slonik_submitEvent((SlonikStmt*)stmt,adminfo1,&query,stmt->hdr.script,0);
+	dstring_terminate(&query);
+	if (db_commit_xact((SlonikStmt *) stmt, adminfo1) < 0)
+	{
+		dstring_free(&query);
+		return -1;
+	}
+
+
+
+
 	if (db_begin_xact((SlonikStmt *) stmt, adminfo1,false) < 0)
 		return -1;
 
@@ -3872,6 +3908,41 @@ slonik_set_add_sequence(SlonikStmt_set_add_sequence * stmt)
 	if (adminfo1 == NULL)
 		return -1;
 
+	/**
+	 * make sure that the origin node is caught up with
+	 * the last event node *before* opening the transaciton
+	 * the 'set add table' will take place in.
+	 *
+	 * Once that transaction is opened and has a lock
+	 * on sl_config_lock the slon for the node  won't be 
+	 * able to process many event types from other nodes.  
+	 * So if the origin is behind it will not be able to catch up
+	 * until the transaction completes.
+	 *
+	 * The slonik_submitEvent(...) that submits the
+	 * setAddSequence event might 'wait' until the
+	 * origin is caught up, so we make sure that the
+	 * origin is caught up before opening the
+	 * transaction.
+	 **/
+	if (db_begin_xact((SlonikStmt *) stmt, adminfo1,false) < 0)
+		return -1;
+	dstring_init(&query);
+	slon_mkquery(&query,"lock table \"_%s\".sl_event_lock;"
+					"select \"_%s\".createEvent('_%s', 'SYNC'); ",
+					stmt->hdr.script->clustername,
+					stmt->hdr.script->clustername,
+					stmt->hdr.script->clustername);
+	slonik_submitEvent((SlonikStmt*)stmt,adminfo1,&query,stmt->hdr.script,0);
+	dstring_terminate(&query);
+	if (db_commit_xact((SlonikStmt *) stmt, adminfo1) < 0)
+	{
+		dstring_free(&query);
+		return -1;
+	}
+
+
+
 	if (db_begin_xact((SlonikStmt *) stmt, adminfo1,false) < 0)
 		return -1;