On Mon, Feb 23, 2015 at 8:57 PM, Fujii Masao wrote:
> So I pushed the patch.
>
Thank you.
--
Michael
On Fri, Feb 20, 2015 at 9:33 PM, Michael Paquier
wrote:
> On Fri, Feb 20, 2015 at 9:12 PM, Fujii Masao wrote:
>> On Tue, Feb 10, 2015 at 10:32 PM, Michael Paquier
>> wrote:
>>> On Mon, Feb 9, 2015 at 8:29 PM, Fujii Masao wrote:
On Sun, Feb 8, 2015 at 2:54 PM, Michael Paquier
wrote:
>
On Fri, Feb 20, 2015 at 9:12 PM, Fujii Masao wrote:
> On Tue, Feb 10, 2015 at 10:32 PM, Michael Paquier
> wrote:
>> On Mon, Feb 9, 2015 at 8:29 PM, Fujii Masao wrote:
>>> On Sun, Feb 8, 2015 at 2:54 PM, Michael Paquier
>>> wrote:
On Fri, Feb 6, 2015 at 4:58 PM, Fujii Masao wrote:
> -
On Tue, Feb 10, 2015 at 10:32 PM, Michael Paquier
wrote:
> On Mon, Feb 9, 2015 at 8:29 PM, Fujii Masao wrote:
>> On Sun, Feb 8, 2015 at 2:54 PM, Michael Paquier
>> wrote:
>>> On Fri, Feb 6, 2015 at 4:58 PM, Fujii Masao wrote:
- * Wait for more WAL to arrive. Time out aft
On Tue, Feb 10, 2015 at 10:32 PM, Michael Paquier wrote:
> Patch updated is attached.
>
Patch moved to CF 2015-02 with same status.
--
Michael
On Mon, Feb 9, 2015 at 8:29 PM, Fujii Masao wrote:
> On Sun, Feb 8, 2015 at 2:54 PM, Michael Paquier
> wrote:
>> On Fri, Feb 6, 2015 at 4:58 PM, Fujii Masao wrote:
>>> - * Wait for more WAL to arrive. Time out after 5
>>> seconds,
>>> - * like when polling
On Sun, Feb 8, 2015 at 2:54 PM, Michael Paquier
wrote:
> On Fri, Feb 6, 2015 at 4:58 PM, Fujii Masao wrote:
>> - * Wait for more WAL to arrive. Time out after 5
>> seconds,
>> - * like when polling the archive, to react to a trigger
>> -
On Fri, Feb 6, 2015 at 4:58 PM, Fujii Masao wrote:
> timestamp.c:1708: warning: implicit declaration of function
> 'HandleStartupProcInterrupts'
>
> I got the above warning at the compilation.
>
> +pg_usleep(wait_time);
> +HandleStartupProcInterrupts();
> +total_time -= wait
On Fri, Feb 6, 2015 at 1:23 PM, Michael Paquier
wrote:
> On Thu, Feb 5, 2015 at 11:58 PM, Michael Paquier wrote:
>> An updated patch is attached.
> I just noticed that the patch I sent was incorrect:
> - Parameter name was still wal_availability_check_interval and not
> wal_retrieve_retry_interval
On Thu, Feb 5, 2015 at 11:58 PM, Michael Paquier wrote:
> An updated patch is attached.
I just noticed that the patch I sent was incorrect:
- Parameter name was still wal_availability_check_interval and not
wal_retrieve_retry_interval
- Documentation was incorrect.
Please use the patch attached ins
Fujii Masao wrote:
> +TimestampDifference(start_time, stop_time, &secs, µsecs);
> +pg_usleep(interval_msec * 1000L - (100L * 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 som
On Tue, Jan 20, 2015 at 12:57 PM, Michael Paquier
wrote:
> On Tue, Jan 20, 2015 at 1:56 AM, Andres Freund wrote:
>> On 2015-01-19 17:16:11 +0900, Michael Paquier wrote:
>>> On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
>>> wrote:
>>> > On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund
>>> > wr
On Tue, Jan 20, 2015 at 1:56 AM, Andres Freund wrote:
> On 2015-01-19 17:16:11 +0900, Michael Paquier wrote:
>> On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
>> wrote:
>> > On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund
>> > wrote:
>> >> Not this patch's fault, but I'm getting a bit tired se
On 2015-01-19 17:16:11 +0900, Michael Paquier wrote:
> On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
> wrote:
> > On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund
> > wrote:
> >> Not this patch's fault, but I'm getting a bit tired seeing the above open
> >> coded. How about adding a function th
On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
wrote:
> On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund wrote:
>> Not this patch's fault, but I'm getting a bit tired seeing the above open
>> coded. How about adding a function that does the sleeping based on a
>> timestamptz and a ms interval?
>
On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
wrote:
> On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund wrote:
>> Am I missing something or does this handle/affect streaming failures
>> just the same? That might not be a bad idea, because the current
>> interval is far too long for e.g. a sync r
On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund wrote:
> On 2015-01-05 17:16:43 +0900, Michael Paquier wrote:
>> + > xreflabel="restore_command_retry_interval">
>> + restore_command_retry_interval
>> (integer)
>> +
>> +restore_command_retry_interval recovery
>> parameter
>>
Hi,
On 2015-01-05 17:16:43 +0900, Michael Paquier wrote:
> + xreflabel="restore_command_retry_interval">
> + restore_command_retry_interval
> (integer)
> +
> +restore_command_retry_interval recovery
> parameter
> +
> +
> +
> +
> +If restor
On Mon, Jan 5, 2015 at 10:39 PM, Alexey Vasiliev wrote:
> Hello. Thanks for help. Yes, new patch look fine!
OK cool. Let's get an opinion from a committer then.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
Mon, 5 Jan 2015 17:16:43 +0900 от Michael Paquier :
> On Wed, Dec 31, 2014 at 12:22 AM, Alexey Vasiliev wrote:
> > Tue, 30 Dec 2014 21:39:33 +0900 от Michael Paquier
> > :
> > As I understand now = (pg_time_t) time(NULL); return time in seconds, what
> > is why I multiply value to 1000 to compar
On Wed, Dec 31, 2014 at 12:22 AM, Alexey Vasiliev wrote:
> Tue, 30 Dec 2014 21:39:33 +0900 от Michael Paquier
> :
> As I understand now = (pg_time_t) time(NULL); return time in seconds, what is
> why I multiply value to 1000 to compare with restore_command_retry_interval
> in milliseconds.
This
Tue, 30 Dec 2014 21:39:33 +0900 от Michael Paquier :
> On Tue, Dec 30, 2014 at 9:33 PM, Michael Paquier
> wrote:
> > On Tue, Dec 30, 2014 at 9:10 PM, Alexey Vasiliev
> > wrote:
> >> To not modify current pg_usleep calculation, I changed
> >> restore_command_retry_interval value to seconds (not m
On Tue, Dec 30, 2014 at 9:33 PM, Michael Paquier
wrote:
> On Tue, Dec 30, 2014 at 9:10 PM, Alexey Vasiliev wrote:
>> To not modify current pg_usleep calculation, I changed
>> restore_command_retry_interval value to seconds (not milliseconds). In this
>> case, min value - 1 second.
> Er, what the
On Tue, Dec 30, 2014 at 9:10 PM, Alexey Vasiliev wrote:
> To not modify current pg_usleep calculation, I changed
> restore_command_retry_interval value to seconds (not milliseconds). In this
> case, min value - 1 second.
Er, what the problem with not changing 100L to 1000L? The unit of
your pa
Hello.
Thanks, I understand, what look in another part of code. Hope right now I did
right changes.
To not modify current pg_usleep calculation, I changed
restore_command_retry_interval value to seconds (not milliseconds). In this
case, min value - 1 second.
Mon, 29 Dec 2014 00:15:03 +0900
On Sat, Dec 27, 2014 at 3:42 AM, Alexey Vasiliev wrote:
> Thanks for suggestions.
>
> Patch updated.
Cool, thanks. I just had an extra look at it.
+This is useful, if I using for restore of wal logs some
+external storage (like AWS S3) and no matter what the slave database
+
Thanks for suggestions.
Patch updated.
Mon, 22 Dec 2014 12:07:06 +0900 от Michael Paquier :
>On Tue, Nov 4, 2014 at 6:25 AM, Alexey Vasiliev < leopard...@inbox.ru > wrote:
>> Added new patch.
>Seems useful to me to be able to tune this interval of time.
>
>I would simply reword the documentatio
On Tue, Nov 4, 2014 at 6:25 AM, Alexey Vasiliev wrote:
> Added new patch.
Seems useful to me to be able to tune this interval of time.
I would simply reword the documentation as follows:
If restore_command returns nonzero exit status code, retry
command after the interval of time specified by thi
Tue, 4 Nov 2014 14:41:56 +0100 от Andres Freund :
> Hi,
>
> On 2014-11-03 14:04:00 +0300, Alexey Vasiliev wrote:
> > * What the patch does in a short paragraph: This patch should add option
> > recovery_timeout, which help to control timeout of restore_command nonzero
> > status code. Right
Hi,
On 2014-11-03 14:04:00 +0300, Alexey Vasiliev wrote:
> * What the patch does in a short paragraph: This patch should add option
> recovery_timeout, which help to control timeout of restore_command nonzero
> status code. Right now default value is 5 seconds. This is useful, if I using
> for
Mon, 3 Nov 2014 22:55:02 -0200 от Fabrízio de Royes Mello
:
>
>
>
> On Mon, Nov 3, 2014 at 7:25 PM, Alexey Vasiliev < leopard...@inbox.ru > wrote:
> >
> >
> >
> >
> > Mon, 3 Nov 2014 19:18:51 -0200 от Fabrízio de Royes Mello <
> > fabriziome...@gmail.com >:
> > >
> > > >
> > > > Should I ch
On Mon, Nov 3, 2014 at 7:25 PM, Alexey Vasiliev wrote:
>
>
>
>
> Mon, 3 Nov 2014 19:18:51 -0200 от Fabrízio de Royes Mello <
fabriziome...@gmail.com>:
> >
> > >
> > > Should I change my patch and send it by email? And also as I
understand I should change message ID for
https://commitfest.postgresq
Mon, 3 Nov 2014 19:18:51 -0200 от Fabrízio de Royes Mello
:
>
> >
> > Should I change my patch and send it by email? And also as I understand I
> > should change message ID for
> > https://commitfest.postgresql.org/action/patch_view?id=1636 , isn't it?
> >
>
> You should just send another
>
> Should I change my patch and send it by email? And also as I understand I
should change message ID for
https://commitfest.postgresql.org/action/patch_view?id=1636, isn't it?
>
You should just send another version of your patch by email and add a new
"comment" to commit-fest using the "Patch" c
Mon, 03 Nov 2014 14:36:33 -0500 от Peter Eisentraut :
> On 11/3/14 6:04 AM, Alexey Vasiliev wrote:
> > 3. What the patch does in a short paragraph: This patch should add
> > option recovery_timeout, which help to control timeout of
> > restore_command nonzero status code. Right now default
On 11/3/14 6:04 AM, Alexey Vasiliev wrote:
> 3. What the patch does in a short paragraph: This patch should add
> option recovery_timeout, which help to control timeout of
> restore_command nonzero status code. Right now default value is 5
> seconds. This is useful, if I using for rest
Hello everyone.
* Project name: Add recovery_timeout option to control timeout of
restore_command nonzero status code
* Uniquely identifiable file name, so we can tell difference between your v1
and v24: 0001-add-recovery_timeout-to-controll-timeout-between-res.patch
* What the patch does
37 matches
Mail list logo
