Richard Yen <dba at richyen.com> writes:

>> If the origin is not being updated, then it may take 30 seconds to
>> generate a SYNC (depending on configuration!).  In that case,
>> subscribers may sit at the same SYNC number as the origin for that 30
>> seconds.
> Are you referring to the sync_interval_timeout parameter in my conf
> file?  I'm set to sync_interval_timeout=3000
>
> I'm also set to sync_interval=500.  Is this supposed to create a SYNC
> event every .5 seconds?  Or perhaps the subscriber is supposed to
> look for a SYNC event every .5 seconds?
>
> Perhaps my understanding of SYNC is misshapen, and it's being exposed
> here...

You've got the right parameters...

- sync_interval, defaulting to 2000ms (per 1.2), indicates how often the work
  loop waits to consider doing another SYNC.

  In effect, SYNCs will always be *at least* sync_interval
  milliseconds apart.

- sync_interval_timeout, defaulting to 10000 (per 1.2) indicates the
  longest that the work loop will wait to generate a SYNC, if there has
  been no activity in that interval.

  Thus, SYNCs will be *at most* sync_interval_timeout milliseconds
  apart.

With your figures of 500 and 3000, there will be at most a SYNC every
0.5s, and at least, one every 3.0s (with a bit of fuzziness if things
are pretty busy; the times might be a *little* more).

>> After 30s, one of the timeouts is reached, a SYNC (that involves no
>> updates!) is generated, and so it takes very little time for the
>> subscribers to process that SYNC, and then sit, lagging by nothing,
>> for another 30s.
>>
>> If the application is quiescent, then that's a to-be-expected
>> behaviour.
> Thanks for the response!

If your sync_interval_timeout is 3000, then there shouldn't be 30s
periods; there should only be 3s periods.  So I'm not sure where you'd
get 30 seconds of 'nothing changing.'

Actually, I think you could quite reasonably increase that timeout
interval; note that if there *are* updates, the sync_interval value of
500ms will pick them up and generate a SYNC within 0.5s.  There isn't
any particular risk in increasing sync_interval_timeout to a higher
value; you won't lose table data as a result of that.

The one risk that *would* be taken in increasing sync_interval_timeout
is that if you're doing a lot of sequence updates that *do not* any
involve updates to replicated tables, the sequence updates might not
get replicated for a while.  And I have to really squint at it to
imagine that this is terribly much of a risk.  The usual usage of
sequences to manage values in SERIAL-like columns leads to INSERTs
taking place lock-step with the sequence updates.
-- 
(reverse (concatenate 'string "ofni.sesabatadxunil" "@" "enworbbc"))
http://linuxdatabases.info/info/unix.html
"It is not enough to succeed, others must fail."  -- Gore Vidal