Jan
On 6/6/2004 2:33 PM, Jeff Davis wrote:
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
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
