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:

remoteListenThread_%d: timeout (%d s) for event selection\n"

(Fill in values as needed :-).)

The initial COPY has completed, but the slon could get stuck at that
point, timing out repeatedly.  If so, then setting the config option
remote_listen_timeout to something larger than 300 will allow it to
get past that problem.

And it is by no means certain that there WILL be a failure there; it's
just that it's *possible*, and that's a reasonable resolution.
-- 
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"