On Fri, Oct 20, 2017 at 3:46 AM, Eric Radman <ericsh...@eradman.com> wrote: > On Tue, Oct 17, 2017 at 12:34:17PM +0900, Michael Paquier wrote: >> On Tue, Oct 17, 2017 at 12:51 AM, Eric Radman <ericsh...@eradman.com> 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. >> >> I see what you are trying to achieve and that seems worth it. It is >> indeed a waste to not have a WAL receiver online while waiting for a >> delay to be applied. > ... >> If you think about it, no parameters are actually needed. What you >> should try to achieve is to make recoveryApplyDelay() smarter, > > This would be even better. Attached is the 2nd version of this patch > that I'm using until an alternate solution is developed.
I definitely agree that a better handling of WAL receiver restart would be done, however this needs and a better-thought refactoring which is not this patch provides, so I am marking it as returned with feedback. People looking for a solution, and not using archiving (because your patch breaks it), could always apply what you have as a workaround. -- Michael
