The same transaction should not have both a row in sl_event and log data
to sl_log_1 or sl_log_2 with the logTrigger.  This is not something slonik
would ever do, and the data changes that the logTrigger logs might not get
replicated as part of the event processing(ie for many non SYNC events).
it is also unclear what order the data should be applied in with respect to
the actions of the non-SYNC event.
---
 src/backend/slony1_funcs.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/backend/slony1_funcs.c b/src/backend/slony1_funcs.c
index 2d8891b..657589e 100644
--- a/src/backend/slony1_funcs.c
+++ b/src/backend/slony1_funcs.c
@@ -151,7 +151,8 @@ typedef struct slony_I_cluster_status
 	text	   *cmdtype_I;
 	text	   *cmdtype_U;
 	text	   *cmdtype_D;
-
+	bool	   event_txn;
+	
 	struct slony_I_cluster_status *next;
 }	Slony_I_ClusterStatus;
 
@@ -257,6 +258,12 @@ versionFunc(createEvent) (PG_FUNCTION_ARGS)
 	if (!TransactionIdEquals(cs->currentXid, newXid))
 	{
 		cs->currentXid = newXid;
+		cs->event_txn = true;
+	}
+
+	if(!cs->event_txn)
+	{
+		elog(ERROR,"createEvent called in a data transaction");
 	}
 
 	/*
@@ -467,8 +474,13 @@ versionFunc(logTrigger) (PG_FUNCTION_ARGS)
 		}
 
 		cs->currentXid = newXid;
+		cs->event_txn=false;
 	}
 
+	if(cs->event_txn)
+	{
+		elog(ERROR,"Slony-I: log trigger called in an event transaction");
+	}
 	/*
 	 * Save the current datestyle setting and switch to ISO (if not already)
 	 */
-- 
2.1.4


--------------080604070207020307040604--