On 8/22/2012 11:45 AM, Christopher Browne wrote:
> On Wed, Aug 22, 2012 at 11:34 AM, Jan Wieck <JanWieck at yahoo.com> wrote:
>> On 8/21/2012 6:16 PM, Christopher Browne wrote:
>>>
>>> The one thing that I'd be a *bit* concerned about is the 57K event
>>> lag.  At one point, I recall there being a possible troublesome case
>>> where one of the queries for the first SYNC processing after that
>>> could time out when trying to read in all of the tens of thousands of
>>> events.  It would be nicer if, during this laggy period, SYNCs got
>>> generated somewhat less often, let's say, every 10-20s rather than
>>> every 0.5s.
>>
>>
>> That can only happen on slon startup, when the remote_listen thread selects
>> all NEW events. During the copy_set(), the remote listener is still getting
>> these events and queues them in memory.
>>
>> Unless something is interrupting the copy, I'm not worried yet.
>
> Agreed.
>
> I do recall seeing trouble come up *afterwards*, if there were so many
> events to process that it took too long to run the query to draw them
> in.
>
> Ah, poking at the code is useful.  There is a configuration option for
> this, remote_listen_timeout, which defaults to 300 seconds, but might
> be set higher.
>
> If, after the subscription completes, there are wildly too many SYNC
> events lingering around, and it takes too long to process them, the
> remote_listen thread will time out, complaining thus:

You are missing the point. However many unprocessed SYNC events there 
will be after the copy, the remote_listener will have shoveled them into 
memory as they appeared already. There is no BIG EVENT SELECT after the 
copy.



-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin