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.

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.



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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20070814/=
c5bb31ac/attachment.htm