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.