On Sun, 2004-06-06 at 10:32, Jan Wieck wrote:
> You are right. The "local" slon node checks every "-s" milliseconds
> (commandline switch) if the sequence sl_action_seq has changed, and if
> so generate a SYNC event. Bumping a sequence alone does not cause this,
> only operations that invoke the log trigger on replicated tables do.
>
> Speaking of this, this would also mean that there is a gap between the
> last sl_action_seq bumping operation and the commit of that transaction.
> If the local slon will generate the sync right in that gap, the changes
> done in that transaction will not be replicated until the next
> transaction triggers another sync.
>
> I am not sure how to effectively avoid this problem without blindly
> creating SYNC events in a maybe less frequent interval. Suggestions?
A couple thoughts occur to me:
Spurious SYNCs might not be the end of the world, because if someone is
using replication, they probably don't mind the unneeded costs of a SYNC
when the database is not being used heavily. If it is being used
heavily, the SYNCs will have to happen anyway.
Also, it might be possibly to make use of NOTIFY somehow, because
notifications only occur after a transaction commits. Perhaps you can
issue a notify for each transaction that modifies a replicated table and
slon could listen for that notification? That way, it wouldn't SYNC
before the transaction commits and miss the uncommitted data.
Regards,
Jeff Davis
