On Wed, Nov 19, 2014 at 10:20 AM, Michael Paquier
wrote:
>
>
> On Tue, Nov 18, 2014 at 2:36 AM, Fujii Masao wrote:
>>
>> On Thu, Nov 13, 2014 at 12:38 PM, Fujii Masao
>> wrote:
>> > Thanks for reviewing the patch!
>> >
>> > On Thu, Nov 13, 2014 at 4:05 AM, Alvaro Herrera
>> > wrote:
>> >> Fujii
On Tue, Nov 18, 2014 at 2:36 AM, Fujii Masao wrote:
> On Thu, Nov 13, 2014 at 12:38 PM, Fujii Masao
> wrote:
> > Thanks for reviewing the patch!
> >
> > On Thu, Nov 13, 2014 at 4:05 AM, Alvaro Herrera
> > wrote:
> >> Fujii Masao wrote:
> >>
> >>> --- 127,152
> >>>When this opti
On Thu, Nov 13, 2014 at 12:38 PM, Fujii Masao wrote:
> Thanks for reviewing the patch!
>
> On Thu, Nov 13, 2014 at 4:05 AM, Alvaro Herrera
> wrote:
>> Fujii Masao wrote:
>>
>>> --- 127,152
>>>When this option is used, pg_receivexlog will
>>> report
>>>a flush positio
Thanks for reviewing the patch!
On Thu, Nov 13, 2014 at 4:05 AM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>
>> --- 127,152
>>When this option is used, pg_receivexlog will
>> report
>>a flush position to the server, indicating when each segment has
>> been
>>
Fujii Masao wrote:
> --- 127,152
>When this option is used, pg_receivexlog will
> report
>a flush position to the server, indicating when each segment has
> been
>synchronized to disk so that the server can remove that segment if
> it
> ! is not
On Mon, Nov 10, 2014 at 7:19 PM, wrote:
>> On Fri, Oct 31, 2014 at 5:46 PM, wrote:
>> >> > We seem to be going in circles. You suggested having two options,
>> >> > --feedback, and --fsync, which is almost exactly what Furuya posted
>> >> > originally. I objected to that, because I think that u
> On Fri, Oct 31, 2014 at 5:46 PM, wrote:
> >> > We seem to be going in circles. You suggested having two options,
> >> > --feedback, and --fsync, which is almost exactly what Furuya posted
> >> > originally. I objected to that, because I think that user interface
> >> is
> >> > too complicated.
On Fri, Oct 31, 2014 at 5:46 PM, wrote:
>> > We seem to be going in circles. You suggested having two options,
>> > --feedback, and --fsync, which is almost exactly what Furuya posted
>> > originally. I objected to that, because I think that user interface
>> is
>> > too complicated. Instead, I s
> > We seem to be going in circles. You suggested having two options,
> > --feedback, and --fsync, which is almost exactly what Furuya posted
> > originally. I objected to that, because I think that user interface
> is
> > too complicated. Instead, I suggested having just a single option
> > called
On Wed, Oct 22, 2014 at 9:26 AM, Heikki Linnakangas
wrote:
> We seem to be going in circles. You suggested having two options,
> --feedback, and --fsync, which is almost exactly what Furuya posted
> originally. I objected to that, because I think that user interface is too
> complicated. Instead,
On Fri, Oct 24, 2014 at 11:21 PM, Heikki Linnakangas
wrote:
> On 10/24/2014 01:24 PM, furu...@pm.nttdata.co.jp wrote:
>
> Sorry, I'm going around in the circle. But I'd like to say again, I
> don't think this is good idea. It prevents asynchronous
> pg_receivexlog from fsyncing WAL
On 10/24/2014 01:24 PM, furu...@pm.nttdata.co.jp wrote:
Sorry, I'm going around in the circle. But I'd like to say again, I
don't think this is good idea. It prevents asynchronous
pg_receivexlog from fsyncing WAL data and sending feedbacks more
frequently at all. They are useful, for example, whe
> >> Sorry, I'm going around in the circle. But I'd like to say again, I
> >> don't think this is good idea. It prevents asynchronous
> >> pg_receivexlog from fsyncing WAL data and sending feedbacks more
> >> frequently at all. They are useful, for example, when we want to
> >> monitor the write lo
On 10/23/2014 06:01 PM, Simon Riggs wrote:
On 23 October 2014 15:39, Fujii Masao wrote:
Sorry, I'm going around in the circle. But I'd like to say again, I don't think
this is good idea. It prevents asynchronous pg_receivexlog from fsyncing
WAL data and sending feedbacks more frequently at all
On 23 October 2014 15:39, Fujii Masao wrote:
> Sorry, I'm going around in the circle. But I'd like to say again, I don't
> think
> this is good idea. It prevents asynchronous pg_receivexlog from fsyncing
> WAL data and sending feedbacks more frequently at all. They are useful,
> for example, whe
On Wed, Oct 22, 2014 at 10:47 PM, Simon Riggs wrote:
> On 22 October 2014 14:26, Heikki Linnakangas wrote:
>
>> We seem to be going in circles. You suggested having two options,
>> --feedback, and --fsync, which is almost exactly what Furuya posted
>> originally. I objected to that, because I thi
On 22 October 2014 14:26, Heikki Linnakangas wrote:
> We seem to be going in circles. You suggested having two options,
> --feedback, and --fsync, which is almost exactly what Furuya posted
> originally. I objected to that, because I think that user interface is too
> complicated. Instead, I sugg
On 10/17/2014 01:59 PM, Simon Riggs wrote:
On 17 October 2014 09:55, wrote:
A new parameter to send feedback should be called --feedback
A second parameter to decide whether to fsync should be called --fsync
I think keep using "--reply-fsync" and "--fsync-interval" is better than make
n
On 17 October 2014 09:55, wrote:
>>A new parameter to send feedback should be called --feedback
>>A second parameter to decide whether to fsync should be called --fsync
>
> I think keep using "--reply-fsync" and "--fsync-interval" is better than make
> new options.
> Thought?
We already have
> >>> In synchronous mode, pg_receivexlog should have similar logic as
> walreceiver does.
> >>
> >> OK. I understand that removing --fsync-interval has no problem.
> >
> > +1 for adding something like --synchronous option. To me,
> > it sounds walreceiver-compatible mode rather than synchronous.
>
On 10 October 2014 09:28, Fujii Masao wrote:
>>> In synchronous mode, pg_receivexlog should have similar logic as
>>> walreceiver does.
>>
>> OK. I understand that removing --fsync-interval has no problem.
>
> +1 for adding something like --synchronous option. To me,
> it sounds walreceiver-comp
> >> >>> If we remove --fsync-interval, resoponse time to user will not
> be
> >> delay.
> >> >>> Although, fsync will be executed multiple times in a short period.
> >> >>> And there is no way to solve the problem without
> >> >>> --fsync-interval, what
> >> >> should we do about it?
> >> >>
> >>
On Thu, Oct 9, 2014 at 6:42 PM, wrote:
>> >>> If we remove --fsync-interval, resoponse time to user will not be
>> delay.
>> >>> Although, fsync will be executed multiple times in a short period.
>> >>> And there is no way to solve the problem without --fsync-interval,
>> >>> what
>> >> should we
> >>> If we remove --fsync-interval, resoponse time to user will not be
> delay.
> >>> Although, fsync will be executed multiple times in a short period.
> >>> And there is no way to solve the problem without --fsync-interval,
> >>> what
> >> should we do about it?
> >>
> >> I'm sorry, I didn't und
On 10/09/2014 07:47 AM, furu...@pm.nttdata.co.jp wrote:
If we remove --fsync-interval, resoponse time to user will not be delay.
Although, fsync will be executed multiple times in a short period.
And there is no way to solve the problem without --fsync-interval, what
should we do about it?
I'm
> What set of options would you pass if you want to use it as a
> synchronous standby? And if you don't? Could we just have a single
> >> "--synchronous"
> flag, instead of -F and --reply-fsync?
> >>>
> >>> If you set "synchronous_commit" as "remote_write", the options would
> >> be
On 10/08/2014 11:47 AM, furu...@pm.nttdata.co.jp wrote:
On 10/08/2014 07:23 AM, furu...@pm.nttdata.co.jp wrote:
What set of options would you pass if you want to use it as a
synchronous standby? And if you don't? Could we just have a single
"--synchronous"
flag, instead of -F and --reply-fsync
> On 10/08/2014 07:23 AM, furu...@pm.nttdata.co.jp wrote:
> >> What set of options would you pass if you want to use it as a
> >> synchronous standby? And if you don't? Could we just have a single
> "--synchronous"
> >> flag, instead of -F and --reply-fsync?
> >
> > If you set "synchronous_commit"
On 10/08/2014 07:23 AM, furu...@pm.nttdata.co.jp wrote:
What set of options would you pass if you want to use it as a synchronous
standby? And if you don't? Could we just have a single "--synchronous"
flag, instead of -F and --reply-fsync?
If you set "synchronous_commit" as "remote_write", the
> On 09/29/2014 01:13 PM, furu...@pm.nttdata.co.jp wrote:
> >> I don't understand what this patch does. When would you want to use
> >> the new --reply-fsync option? Is there any reason *not* to use it?
> >> In other words, do we need an option for this, couldn't you just
> >> always send the feedb
On 09/29/2014 01:13 PM, furu...@pm.nttdata.co.jp wrote:
I don't understand what this patch does. When would you want to use
the new --reply-fsync option? Is there any reason *not* to use it?
In other words, do we need an option for this, couldn't you just
always send the feedback message after fs
> On 09/05/2014 08:51 AM, furu...@pm.nttdata.co.jp wrote:
> >>> Thanks for the review!
> >>>
> >>> I understand the attention message wasn't appropriate.
> >>>
> >>> To report the write location, even If you do not specify a
> >>> replication
> >> slot.
> >>> So the fix only appended messages.
> >>
On 09/05/2014 08:51 AM, furu...@pm.nttdata.co.jp wrote:
Thanks for the review!
I understand the attention message wasn't appropriate.
To report the write location, even If you do not specify a replication
slot.
So the fix only appended messages.
There was a description of the flush location
> > Thanks for the review!
> >
> > I understand the attention message wasn't appropriate.
> >
> > To report the write location, even If you do not specify a replication
> slot.
> > So the fix only appended messages.
> >
> > There was a description of the flush location section of '-S' option,
> > b
On Fri, Aug 22, 2014 at 1:35 PM, wrote:
>> Thank you for updating the patch.
>> I reviewed the patch.
>>
>> First of all, I think that we should not append the above message to
>> section of '-r' option.
>> (Or these message might not be needed at all) Whether flush location in
>> feedback messag
> Thank you for updating the patch.
> I reviewed the patch.
>
> First of all, I think that we should not append the above message to
> section of '-r' option.
> (Or these message might not be needed at all) Whether flush location in
> feedback message is valid, is not depend on '-r' option.
>
>
On Thu, Aug 21, 2014 at 2:54 PM, wrote:
>> When replication slot is not specified in pg_receivexlog, the flush
>> location in the feedback message always indicates invalid. So there seems
>> to be no need to send the feedback as soon as fsync is issued, in that
>> case.
>> How should this option
> When replication slot is not specified in pg_receivexlog, the flush
> location in the feedback message always indicates invalid. So there seems
> to be no need to send the feedback as soon as fsync is issued, in that
> case.
> How should this option work when replication slot is not specified?
T
On Tue, Aug 19, 2014 at 9:52 AM, wrote:
>> Thank you for updating the patch.
>>
>> I did not get error with applying, and compiling.
>> It works fine. I think this function code has no problem.
>> Could you please submit patch to commit fest app?
>
> Thanks for the review!
>
> As you pointed out,
> Thank you for updating the patch.
>
> I did not get error with applying, and compiling.
> It works fine. I think this function code has no problem.
> Could you please submit patch to commit fest app?
Thanks for the review!
As you pointed out, submitted patch to commit fest app.
Regards,
--
F
On Mon, Aug 18, 2014 at 7:55 PM, wrote:
> Thanks for the review!
>
>> One question is why reply_fsync is defined as volatile variable?
>> Sorry I could not understand reason of that.
>
> It was affected to time_to_abort -- since it is unnecessary, it deletes.
>
>> Currently patch modifies argumen
Thanks for the review!
> One question is why reply_fsync is defined as volatile variable?
> Sorry I could not understand reason of that.
It was affected to time_to_abort -- since it is unnecessary, it deletes.
> Currently patch modifies argument of some function (e.g., Handle
> CopyStream, Proc
On Wed, Aug 13, 2014 at 5:55 PM, wrote:
>> I don't think that it's good idea to control that behavior by using
>> --status-interval. I'm sure that there are some users who both want that
>> behavior and want set the maximum interval between a feedback is sent
>> back to the server because these s
> I don't think that it's good idea to control that behavior by using
> --status-interval. I'm sure that there are some users who both want that
> behavior and want set the maximum interval between a feedback is sent
> back to the server because these settings are available in walreceiver.
> But yo
On Tue, Aug 12, 2014 at 6:19 PM, wrote:
> Hi all,
>
> This patch is to add setting to send status packets after fsync to
> --status-interval of pg_receivexlog.
>
> If -1 is specified to --status-interval, status packets is sent as soon as
> after fsync.
I don't think that it's good idea to con
Hi all,
This patch is to add setting to send status packets after fsync to
--status-interval of pg_receivexlog.
If -1 is specified to --status-interval, status packets is sent as soon as
after fsync.
Others are the same as when 0 is specified to --status-interval.
When requested by the server,
46 matches
Mail list logo
