Explicitly disallow createEvent and data changes in the same transaction.
authorSteve Singer <[email protected]>
Sun, 26 Mar 2017 16:54:46 +0000 (12:54 -0400)
committerSteve Singer <[email protected]>
Sun, 26 Mar 2017 16:54:46 +0000 (12:54 -0400)
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

index 2d8891b4184151b3dbe1205ffa3265c825425ee2..657589e9216680bcdb3f61895a999e27b6f62860 100644 (file)
@@ -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)
         */