Hi Slony Folks,

I'm supporting a web application that uses a replicated sequence to
track I/U/D transactions across multiple nodes.  Whenever the
application issues Insert/Update/Delete queries against the origin node
it increments transaction_id_seq and stores the value in memcache.
Before the application issues SELECT queries against a subscriber node,
it compares the value of transaction_id in memcache with the value on a
subscriber.  If the subscriber's value is greater-than or equal-to the
value in memcache, the application issues the SELECT against the
subscriber.  If not, the application knows the subscriber's data is
stale and issues the SELECT against the origin.  This is our
application's solution to replication lag.

I'd like to verify that this approach to replication lag works with the
way Slony orders replication events.

Consider the below example. Does Slony guarantee that the updated
sequence will always appear after (or concurrently with) the result of
the I/U/D statements on subscriber nodes?

For example:
  BEGIN;
  --
  -- write statements
  --
  INSERT into table1 values (...);
  INSERT into table2 values (...);
  UPDATE table3 set col1='x' where col5='y';

  --
  -- increment transaction_id in postgresql and memcache
  --
  SELECT nextval('transaction_id_seq');
  -- application code sets memcache max_transaction_id
  -- to curval('vibe_transaction_id')
  COMMIT;


Thanks for your advice,

Dane

-- 
Dane Miller
Systems Administrator
Greatschools, Inc
http://www.greatschools.net