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 _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
