Re: [HACKERS] [PATCH] Add recovery_min_apply_delay_reconnect recovery option

2017-10-19 Thread Eric Radman
On Tue, Oct 17, 2017 at 12:34:17PM +0900, Michael Paquier wrote: > On Tue, Oct 17, 2017 at 12:51 AM, Eric Radman wrote: > > This administrative compromise is necessary because the WalReceiver is > > not resumed after a network interruption until all records are read, > >

Re: [HACKERS] [PATCH] Add recovery_min_apply_delay_reconnect recovery option

2017-10-17 Thread Michael Paquier
On Tue, Oct 17, 2017 at 10:40 PM, Eric Radman wrote: > On Tue, Oct 17, 2017 at 12:34:17PM +0900, Michael Paquier wrote: > I thought I had observed cases where the WalReceiver was shut down > without causing XLogCtl->recoveryWakeupLatch to return. If I'm wrong > about this

Re: [HACKERS] [PATCH] Add recovery_min_apply_delay_reconnect recovery option

2017-10-17 Thread Eric Radman
On Tue, Oct 17, 2017 at 12:34:17PM +0900, Michael Paquier wrote: > On Tue, Oct 17, 2017 at 12:51 AM, Eric Radman wrote: > > This administrative compromise is necessary because the WalReceiver is > > not resumed after a network interruption until all records are read, > >

Re: [HACKERS] [PATCH] Add recovery_min_apply_delay_reconnect recovery option

2017-10-16 Thread Michael Paquier
On Tue, Oct 17, 2017 at 12:51 AM, Eric Radman wrote: > This administrative compromise is necessary because the WalReceiver is > not resumed after a network interruption until all records are read, > verified, and applied from the archive on disk. Taking a step back here...

[HACKERS] [PATCH] Add recovery_min_apply_delay_reconnect recovery option

2017-10-16 Thread Eric Radman
This is a patch I am using in production using the following parameters in recovery.conf: recovery_min_apply_delay = '1d' recovery_min_apply_delay_reconnect = '10 min' In our environment we expect that standby servers with an apply delay provide some protection against mistakes by the