In response to "Dmitry Koterov" <dmitry at koterov.ru>:

> I agree that the cost is high.
> 
> But seems it's the only method to check a subscriber status relative to the
> origin one after the concrete session (e.g. after a web-script finish). Only
> with timestamps we could deduce and then - use for checking the time of a
> transaction commit without an additional query.

I'm going to repeat myself: maybe Slony isn't the right system for you.

I'm not aware of any of Slony's design goals involving user programs being
able to monitor which transactions have been replicated.  In fact, one of the
nice features of Slony is that it can tolerate communication failures between
nodes, and "catch up" when communication is restored.

It sounds to me that you have some requirement that the transaction be
guaranteed complete before moving to a subsequent step.  To me, that says
you should be using 2-phase commit, no Slony.  I'd be curious to hear your
justification for spending so much effort trying to make Slony do something
it was never intended to do when you have a system that _does_ what you need.

> Now I am trying to achieve the same result without Slony schema
> modification, but with the cost of additional query at the end of a session
> (it is "SELECT getcurrentxid()" query). Hope it will work fine. Possibly
> this method is in general much better than the method with timestamps. Will
> write soon.

In any event, I hope you find a solution that works.  I'm still completely
mystified as to why you're doing it.

> On 8/13/07, Christopher Browne <cbbrowne at ca.afilias.info> wrote:
> >
> > Dmitry Koterov wrote:
> > > Seems my task could be completely solved if we change Slony's schema
> > > adding:
> > >
> > > 1. a new field sl_log_*.log_timestamp (set to now() by default)
> > Seems like a cost to outweigh the value of the result.  This adds a
> > timestamp (and evaluation of time) to every tuple that is processed,
> > which will make replication more expensive and slower, to the
> > application, and for what?  So that once in a while the timestamp may be
> > accessed?
> > > 2. a new field sl_event.ev_mintimestamp (the minimum timestamp of
> > > included modifications or, if there are no modifications, a sync
> > > creation time)
> > >
> > Insertions to sl_event take place, at present, as a simple insert.
> >
> > To add this timestamp would require running the query that identifies
> > all sl_log_* entries that are associated with a given SYNC, and
> > aggregate that to find the earliest value of sl_log_*.log_timestamp.
> >
> > If the addition of sl_log_*.log_timestamp adds a *bit* of work, this
> > change would add in an *enormous* amount of work; this would make a SYNC
> > event, on the master, merely to identify the one timestamp, as expensive
> > as adding an extra replication node.
> > > So we could check if a subscriber has already processed an event
> > > generated strictly after the specified master time.
> > In principle, we could, at the cost of making replication *massively*
> > more expensive.
> >
> > It is not obvious that people will agree that this information is of
> > such value that it warrants paying that price.
> >
> 
> 
> 
> 
> 
> 
> 


-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran at collaborativefusion.com
Phone: 412-422-3463x4023

****************************************************************
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************