On 2/11/2008 3:48 PM, Bill Moran wrote:
> Keep in mind that Slony was not _designed_ to work over unreliable
> connections.  The fact that it does a pretty good job anyway is a
> testament to good design.

Thanks for that endorsement.

> However, a very busy database will have a hellatius time keeping in
> sync over a flakey connection.  Also, the term "unreliable" means
> different things to different people: some people consider a connection
> merely "unreliable" if it drops less than 20% of packets on a regular
> basis, whereas I would call such a connection outright "broken".

At least you can rely on the fact that the ack and retrans efforts done 
by the TCP stack aren't for nothing ... one might call that "reliable".

Jokes aside, what is more important than packet loss by itself is how 
the connection handles loss of connection. There are many cheap routers 
out there that, when doing some crappy sort of network address 
translation, they not only drop idle connections. I have seen enough of 
these things really dropping them literally, without even bothering to 
send the appropriate TCP notification that the connection was reset.

Slony does not use TCP_KEEPALIVE on its sockets (after all, they are 
standard libpq connections). So if a connection is entirely used to 
listen on a backend for NOTIFY, a thusly dropped connection will make 
that particular listen wait forever.


Jan

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