On 13/11/18 5:35 μ.μ., Rui DeSousa wrote:
Is there a way for the WAL receiver to not have detected the termination of the replication stream?
The teardown of the network socket on the upstream server should send a reset packet to the downstream server and at that point the WAL receiver would close its connection. Is there any firewalls, router, rules, etc between the nodes that could have dropped the packet?
No
Shouldn't normally the WAL receiver detect this and try again in wal_retrieve_retry_interval ?
Not really… if the connection has already been torn down; the upstream server would send another reset packet on the next request and in this case it would. However, if request packets at not reaching the upstream server; i.e. due to firewall silently dropping the packets (personally I believe firewall should always set reset packets to friendly hosts) then what happens is the TCP/IP send queue builds up with the requests packets instead — a t this point waiting on the OS to terminate the connection which can day or two depending on your TCP/IP setting.
Again no dropping, no firewall.
What you want to use instead is wal_receiver_timeout to detect the given case where upstream server either no longer exists or the firewall, etc is silently dropping packets.
Once again from my original message :
"while setting up logical replication since August we had seen early on the need to increase max_receiver_timeout and max_sender_timeout from 60sec to 5mins"
So with wal_receiver_timeout='5 min', the receiver never detected any timeout.
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt
