Re: Patch: add recovery_timeout option to control timeout of restore_command nonzero status code

Fujii Masao wrote:
> + TimestampDifference(start_time, stop_time, &secs, &microsecs);
> + pg_usleep(interval_msec * 1000L - (1000000L * secs + 1L * microsecs));
>
> What if the large interval is set and a signal arrives during the sleep?
> I'm afraid that a signal cannot terminate the sleep on some platforms.
> This problem exists even now because pg_usleep is used, but the sleep
> time is just 5 seconds, so it's not so bad. But the patch allows a user to
> set large sleep time.

Yes, and I thought that we could live with that for this patch... Now
that you mention it something similar to what recoveryPausesHere would
be quite good to ease the shutdown of a process interrupted, even more
than now as well. So let's do that.

> Shouldn't we use WaitLatch or split the pg_usleep like recoveryPausesHere() does?

I'd vote for the latter as we would still need to calculate a
timestamp difference in any cases, so it feels easier to do that in
the new single API and this patch does (routine useful for plugins as
well). Now I will not fight if people think that using
recoveryWakeupLatch is better.

An updated patch is attached. This patch contains as well a fix for
something that was mentioned upthread but not added in latest version:
wal_availability_check_interval should be used when waiting for a WAL
record from a stream, and for a segment when fetching from archives.
Last version did only the former, not the latter.
--
Michael