On Fri, Oct 20, 2017 at 3:46 AM, Eric Radman <ericshane@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 <ericshane@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
