Slony-I REL_1_1_0 Documentation
Prev | Fast Backward |  | Fast Forward | Next

# 3. Event Tuning

`sync_interval` (`integer`)

  Check for updates at least this often in milliseconds. Range: [10-60000], default 100

`sync_interval_timeout` (`integer`)

  Maximum amount of time in milliseconds before issuing a `SYNC` event, This prevents a possible race condition in which the action sequence is bumped by the trigger while inserting the log row, which makes this bump is immediately visible to the sync thread, but the resulting log rows are not visible yet. If the `SYNC` is picked up by the subscriber, processed and finished before the transaction commits, this transaction's changes will not be replicated until the next `SYNC`. But if all application activity suddenly stops, there will be no more sequence bumps, so the high frequent `-s` check won't detect that. Thus, the need for `sync_interval_timeout`. Range: [0-120000], default 1000

`sync_group_maxsize` (`integer`)

  Maximum number of `SYNC` events to group together when/if a subscriber falls behind. `SYNC`s are batched only if there are that many available and if they are contiguous. Every other event type in between leads to a smaller batch. And if there is only one `SYNC` available, even `-g60` will apply just that one. As soon as a subscriber catches up, it will apply every single `SYNC` by itself. Range: [0,10000], default: 6

`vac_frequency` (`integer`)

  Sets how many cleanup cycles to run before a vacuum is done. 0 disables the builtin vacuum, intended to be used with the pg_autovacuum daemon. Range: [0,100], default: 3

`desired_sync_time` (`integer`)

  Maximum time planned for grouped `SYNC`s. If replication is behind, slon will try to increase numbers of syncs done targetting that they should take this quantity of time to process. This is in Range [10000,600000] ms, default 60000.

  If the value is set to 0, this logic will be ignored.

Prev | Home | Next
Connection settings | Up | slonik