On Tue, Nov 18, 2014 at 2:36 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Nov 13, 2014 at 12:38 PM, Fujii Masao masao.fu...@gmail.com
wrote:
Thanks for reviewing the patch!
On Thu, Nov 13, 2014 at 4:05 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Fujii Masao wrote:
On Wed, Nov 19, 2014 at 10:20 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Nov 18, 2014 at 2:36 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Nov 13, 2014 at 12:38 PM, Fujii Masao masao.fu...@gmail.com
wrote:
Thanks for reviewing the patch!
On Thu, Nov 13, 2014
On Thu, Nov 13, 2014 at 12:38 PM, Fujii Masao masao.fu...@gmail.com wrote:
Thanks for reviewing the patch!
On Thu, Nov 13, 2014 at 4:05 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Fujii Masao wrote:
--- 127,152
When this option is used, applicationpg_receivexlog/
On Mon, Nov 10, 2014 at 7:19 PM, furu...@pm.nttdata.co.jp wrote:
On Fri, Oct 31, 2014 at 5:46 PM, furu...@pm.nttdata.co.jp 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
Fujii Masao wrote:
--- 127,152
When this option is used, applicationpg_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
!
On Fri, Oct 31, 2014 at 5:46 PM, furu...@pm.nttdata.co.jp 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
On Fri, Oct 31, 2014 at 5:46 PM, furu...@pm.nttdata.co.jp 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.
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
hlinnakan...@vmware.com 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
On Fri, Oct 24, 2014 at 11:21 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
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 location of
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,
On Wed, Oct 22, 2014 at 10:47 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 22 October 2014 14:26, Heikki Linnakangas hlinnakan...@vmware.com wrote:
We seem to be going in circles. You suggested having two options,
--feedback, and --fsync, which is almost exactly what Furuya posted
On 23 October 2014 15:39, Fujii Masao masao.fu...@gmail.com 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,
On 10/23/2014 06:01 PM, Simon Riggs wrote:
On 23 October 2014 15:39, Fujii Masao masao.fu...@gmail.com 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
On 10/17/2014 01:59 PM, Simon Riggs wrote:
On 17 October 2014 09:55, furu...@pm.nttdata.co.jp 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
On 22 October 2014 14:26, Heikki Linnakangas hlinnakan...@vmware.com 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
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.
Better to add
On 17 October 2014 09:55, furu...@pm.nttdata.co.jp 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
On 10 October 2014 09:28, Fujii Masao masao.fu...@gmail.com 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
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 understand that.
On Thu, Oct 9, 2014 at 6:42 PM, 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
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
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 understand that.
Here is
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 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,
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?
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 different .
The set of options
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
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
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
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
On Fri, Aug 22, 2014 at 1:35 PM, furu...@pm.nttdata.co.jp 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
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,
but I intended to
On Thu, Aug 21, 2014 at 2:54 PM, furu...@pm.nttdata.co.jp 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
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.
If we
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?
On Tue, Aug 19, 2014 at 9:52 AM, furu...@pm.nttdata.co.jp 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
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, Process
On Mon, Aug 18, 2014 at 7:55 PM, furu...@pm.nttdata.co.jp 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
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,
--
On Wed, Aug 13, 2014 at 5:55 PM, furu...@pm.nttdata.co.jp 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
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 your
On Tue, Aug 12, 2014 at 6:19 PM, furu...@pm.nttdata.co.jp 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
44 matches
Mail list logo
