Understood. Really thought I exhausted all potential issues before
submitting this. However, does still seem like the orphaned xlogs
should be cleaned up if they predate the latest checkpoint.
On 02/17/2016 04:21 PM, Venkata Balaji N wrote:
>
> On Thu, Feb 18, 2016 at 5:42 AM, Nick Bales <nick.bales@rackspace.com
> <mailto:nick.bales@rackspace.com>> wrote:
>
> I am not seeing any instances of where the standby nodes are
> falling behind the primary. However, I do see several instances
> each day where the standby is having to re-establish the streaming
> connection to the primary:
>
> 2015-12-15 07:25:10 GMT 12969 XX000 566f9ae1.32a9 0 FATAL: could
> not send data to WAL stream: server closed the connection
> unexpectedly
> 2015-12-15 07:25:10 GMT 33302 00000 566fc056.8216 0 LOG: started
> streaming WAL from primary at 374/F1000000 on timeline 1
> 2015-12-15 10:05:13 GMT 33302 XX000 566fc056.8216 0 FATAL: could
> not send data to WAL stream: server closed the connection
> unexpectedly
> 2015-12-15 10:05:13 GMT 5001 00000 566fe5d9.1389 0 LOG: started
> streaming WAL from primary at 375/11000000 on timeline 1
>
> Upon closer inspection, the number of times this is occurring per
> day does correspond to the number of orphaned xlogs for the day(by
> file's last updated timestamp), so there does seem to be some
> relevance. Will need to investigate further as to what is causing
> the streaming connection to drop.
>
>
> Thats the issue, there is an interruption in streaming probably due to
> network related issues. That needs to be fixed first.
> So, this is not a BUG. Please note that this is not an appropriate
> mailing list to send these technical queries. Please consider sending
> across such technical queries to pgsql-general mailing list.
>
> Regards,
> Venkata B N
>
> Fujitsu Australia
>