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

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Alexey Vasiliev <leopard_ne(at)inbox(dot)ru>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: add recovery_timeout option to control timeout of restore_command nonzero status code
Date: 2015-02-05 19:58:08
Message-ID: CAB7nPqTiRAXj36+GBXdE6F8ynBe+UFCak2wAaXHh8n-Y9aoZ9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
20150205_wal_avail_check_v3.patch text/x-diff 8.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-02-05 21:03:02 Re: SSL renegotiation and other related woes
Previous Message Andres Freund 2015-02-05 19:41:56 Re: s_lock.h default definitions are rather confused