pg_receivexlog --status-interval add fsync feedback

On Tue, Aug 12, 2014 at 6:19 PM, <furuyao@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 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 version of --status-interval doesn't allow those
settings at all. That is, if set to -1, the maximum interval between
each feedback cannot be set. OTOH, if set to the positive number,
feedback-as-soon-as-fsync behavior cannot be enabled. Therefore,
I'm thinking that it's better to introduce new separate option for that
behavior.

Regards,

--
Fujii Masao

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 version of --status-interval doesn't allow those settings at
all. That is, if set to -1, the maximum interval between each feedback
cannot be set. OTOH, if set to the positive number,
feedback-as-soon-as-fsync behavior cannot be enabled. Therefore, I'm
thinking that it's better to introduce new separate option for that
behavior.

Thanks for the review!
This patch was split option as you pointed out.

If -r option is specified, status packets sent to server as soon as after fsync.
Otherwise to send server status packet in the spacing of the --status-interval.

Regards,

--
Furuya Osamu

On Wed, Aug 13, 2014 at 5:55 PM, <furuyao@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 server because these settings are available in walreceiver.
But your version of --status-interval doesn't allow those settings at
all. That is, if set to -1, the maximum interval between each feedback
cannot be set. OTOH, if set to the positive number,
feedback-as-soon-as-fsync behavior cannot be enabled. Therefore, I'm
thinking that it's better to introduce new separate option for that
behavior.

Thanks for the review!
This patch was split option as you pointed out.

If -r option is specified, status packets sent to server as soon as after fsync.
Otherwise to send server status packet in the spacing of the --status-interval.

Hi,

I took a look at this patch.
I applied patch to master successfully, and did not get error with compiling.
Also it works fine.

One question is why reply_fsync is defined as volatile variable?
Sorry I could not understand reason of that.

Currently patch modifies argument of some function (e.g., Handle
CopyStream, Process LogDate Msg), and add the similar code to each
function.
I don't think it is good approach.
For example, I think that we should gather these code into one function.

Thought?

Regards,

-------
Sawada Masahiko

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 LogDate Msg), and add the similar code to each
function.
I don't think it is good approach.
For example, I think that we should gather these code into one function.

Feedback was judged immediately after each fsync until now.
I revised it in reference to walreceiver.
Feedback of fsync is judged together with the judgment of --status-interval.
Thereby, the specification to an argument became minimum.

Regards,

--
Furuya Osamu

On Mon, Aug 18, 2014 at 7:55 PM, <furuyao@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 modifies argument of some function (e.g., Handle
CopyStream, Process LogDate Msg), and add the similar code to each
function.
I don't think it is good approach.
For example, I think that we should gather these code into one function.

Feedback was judged immediately after each fsync until now.
I revised it in reference to walreceiver.
Feedback of fsync is judged together with the judgment of --status-interval.
Thereby, the specification to an argument became minimum.

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?

Regards,

-------
Sawada Masahiko

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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,

--
Furuya Osamu

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Aug 19, 2014 at 9:52 AM, <furuyao@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 pointed out, submitted patch to commit fest app.

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?

Regards,

--
Fujii Masao

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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?

Thanks for the review!

The present is not checking the existence of specification of -S.

The use case when replication slot is not specified.

Because it does fsync, it isn't an original intention.
remote_write is set in synchronous_commit.

To call attention to the user, append following documents.
"If you want to report the flush position to the server, should use -S option."

Regards,

--
Furuya Osamu

On Thu, Aug 21, 2014 at 2:54 PM, <furuyao@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 should this option work when replication slot is not specified?

Thanks for the review!

The present is not checking the existence of specification of -S.

The use case when replication slot is not specified.

Because it does fsync, it isn't an original intention.
remote_write is set in synchronous_commit.

To call attention to the user, append following documents.
"If you want to report the flush position to the server, should use -S option."

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 use '-r' option and 'S' option (i.g., replication slot) then
pg_receivexlog informs valid flush
location to primary server at the same time as doing fsync.
But, if we don't specify replication slot then the flush location in
feedback message always invalid.
So I think Fujii-san pointed out that sending of invalid flush
location is not needed
if pg_receivexlog does not use replication slot.

Regards,

-------
Sawada Masahiko

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 use '-r' option and 'S' option (i.g., replication slot) then
pg_receivexlog informs valid flush location to primary server at the same
time as doing fsync.
But, if we don't specify replication slot then the flush location in
feedback message always invalid.
So I think Fujii-san pointed out that sending of invalid flush location
is not needed if pg_receivexlog does not use replication slot.

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 catch eye more and added a message.

Is it better to make specification of the -S option indispensable?

Regards,

--
Furuya Osamu

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Aug 22, 2014 at 1:35 PM, <furuyao@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
feedback message is valid, is not depend on '-r' option.

If we use '-r' option and 'S' option (i.g., replication slot) then
pg_receivexlog informs valid flush location to primary server at the same
time as doing fsync.
But, if we don't specify replication slot then the flush location in
feedback message always invalid.
So I think Fujii-san pointed out that sending of invalid flush location
is not needed if pg_receivexlog does not use replication slot.

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 catch eye more and added a message.

Is it better to make specification of the -S option indispensable?

The patch cannot be applied to HEAD cleanly. Could you update the patch?

Regards,

--
Fujii Masao

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 catch eye more and added a message.

Is it better to make specification of the -S option indispensable?

The patch cannot be applied to HEAD cleanly. Could you update the patch?

Thank you for pointing out.
Updated the patch.

Regards,

--
Furuya Osamu

On 09/05/2014 08:51 AM, furuyao@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 section of '-S' option,
but I intended to catch eye more and added a message.

Is it better to make specification of the -S option indispensable?

The patch cannot be applied to HEAD cleanly. Could you update the patch?

Thank you for pointing out.
Updated the patch.

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 fsync?

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 09/05/2014 08:51 AM, furuyao@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 section of '-S'
option, but I intended to catch eye more and added a message.

Is it better to make specification of the -S option indispensable?

The patch cannot be applied to HEAD cleanly. Could you update the

patch?

Thank you for pointing out.
Updated the patch.

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 fsync?

Thanks for the comment.

--reply-fsync option is intended for use in synchronous mode.

By specifying -F option and --slot option, process calls fsync() when it received the WAL, and flush location would be set in feedback message.

Interval of sending feedback message depends on -s option in this state, so in the case of synchronous mode, waiting for feedback message would occure.

therefore, --reply-fsync option is necessary. because it can send the feedback message after fsync without waiting for the interval of -s option.

The reason for not sending the feedback message after fsync without waiting for the interval of -s option always, is to answer the needs who want to use fsync only (NOT using synchronous mode).

Regards,

--
Furuya Osamu

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 09/29/2014 01:13 PM, furuyao@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 fsync?

Thanks for the comment.

--reply-fsync option is intended for use in synchronous mode.

By specifying -F option and --slot option, process calls fsync() when
it received the WAL, and flush location would be set in feedback
message.

Interval of sending feedback message depends on -s option in this
state, so in the case of synchronous mode, waiting for feedback
message would occure.

therefore, --reply-fsync option is necessary. because it can send the
feedback message after fsync without waiting for the interval of -s
option.

The reason for not sending the feedback message after fsync without
waiting for the interval of -s option always, is to answer the needs
who want to use fsync only (NOT using synchronous mode).

I still don't get it. AFAICS there are two ways to use pg_receivexlog.
Either you use it as a synchronous standby, or not.

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?

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 09/29/2014 01:13 PM, furuyao@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 fsync?

Thanks for the comment.

--reply-fsync option is intended for use in synchronous mode.

By specifying -F option and --slot option, process calls fsync() when
it received the WAL, and flush location would be set in feedback
message.

Interval of sending feedback message depends on -s option in this
state, so in the case of synchronous mode, waiting for feedback
message would occure.

therefore, --reply-fsync option is necessary. because it can send the
feedback message after fsync without waiting for the interval of -s
option.

The reason for not sending the feedback message after fsync without
waiting for the interval of -s option always, is to answer the needs
who want to use fsync only (NOT using synchronous mode).

I still don't get it. AFAICS there are two ways to use pg_receivexlog.
Either you use it as a synchronous standby, or not.

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?

Thanks for comment.

If you set "synchronous_commit" as "remote_write", the options would be different .
The set of options in each case, see the following.

Synchronous standby(synchronous_commit=on)
--fsync-interval=-1
--reply-fsync
--slot=slotname

Synchronous standby(synchronous_commit=remote_write)
--fsync-interval=-1
--reply-fsync

Asynchronous
There are no relative options.

Well, if the response time delay(value of "--status-interval=interval") is acceptable, "--reply-fsync" is unnecessary.
Instead of "--reply-fsync", using "--synchronous"(which summarizes the "--reply-fsync" and "fsync-interval = -1") might be easy to understand. Although, in that case, "--fsync-interval=interval" would be fixed value. Isn't there any problem ?

Regards,

--
Furuya Osamu

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 10/08/2014 07:23 AM, furuyao@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 options would be different .
The set of options in each case, see the following.

Synchronous standby(synchronous_commit=on)
--fsync-interval=-1
--reply-fsync
--slot=slotname

Synchronous standby(synchronous_commit=remote_write)
--fsync-interval=-1
--reply-fsync

Asynchronous
There are no relative options.

Well, if the response time delay(value of "--status-interval=interval") is acceptable, "--reply-fsync" is unnecessary.
Instead of "--reply-fsync", using "--synchronous"(which summarizes the "--reply-fsync" and "fsync-interval = -1") might be easy to understand. Although, in that case, "--fsync-interval=interval" would be fixed value. Isn't there any problem ?

I think we should remove --fsync-interval and --reply-fsync, and just
have a --synchronous option, which would imply the same behavior you get
with --fsync-interval=-1 --reply--fsync.

That leaves the question of whether pg_receivexlog should do fsyncs when
it's not acting as a synchronous standby. There isn't any real need to
do so. In asynchronous mode, there are no guarantees anyway, and even
without an fsync, the OS will eventually flush the data to disk.

But we could do even better than that. It would be best if you didn't
need even the --synchronous flag. The server knows whether the client is
a synchronous standby or not. It could tell the client.

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 10/08/2014 07:23 AM, furuyao@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 options would

be different .

The set of options in each case, see the following.

Synchronous standby(synchronous_commit=on)
--fsync-interval=-1
--reply-fsync
--slot=slotname

Synchronous standby(synchronous_commit=remote_write)
--fsync-interval=-1
--reply-fsync

Asynchronous
There are no relative options.

Well, if the response time delay(value of

"--status-interval=interval") is acceptable, "--reply-fsync" is
unnecessary.

Instead of "--reply-fsync", using "--synchronous"(which summarizes

the "--reply-fsync" and "fsync-interval = -1") might be easy to
understand. Although, in that case, "--fsync-interval=interval" would
be fixed value. Isn't there any problem ?

I think we should remove --fsync-interval and --reply-fsync, and just
have a --synchronous option, which would imply the same behavior you get
with --fsync-interval=-1 --reply--fsync.

That leaves the question of whether pg_receivexlog should do fsyncs when
it's not acting as a synchronous standby. There isn't any real need to
do so. In asynchronous mode, there are no guarantees anyway, and even
without an fsync, the OS will eventually flush the data to disk.

But we could do even better than that. It would be best if you didn't
need even the --synchronous flag. The server knows whether the client
is a synchronous standby or not. It could tell the client.

Thanks for the reply.

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?

In asynchronous mode, I think there is no problem since the specification is same with release version.

The server knows whether the client is a synchronous standby or not.
It could tell the client.

When notifying the synchronous/asynchronous mode to the client from the server,
do we need to change the format of the Message ?

Regards,

--
Furuya Osamu

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 10/08/2014 11:47 AM, furuyao@pm.nttdata.co.jp wrote:

On 10/08/2014 07:23 AM, furuyao@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 options would

be different .

The set of options in each case, see the following.

Synchronous standby(synchronous_commit=on)
--fsync-interval=-1
--reply-fsync
--slot=slotname

Synchronous standby(synchronous_commit=remote_write)
--fsync-interval=-1
--reply-fsync

Asynchronous
There are no relative options.

Well, if the response time delay(value of

"--status-interval=interval") is acceptable, "--reply-fsync" is
unnecessary.

Instead of "--reply-fsync", using "--synchronous"(which summarizes

the "--reply-fsync" and "fsync-interval = -1") might be easy to
understand. Although, in that case, "--fsync-interval=interval" would
be fixed value. Isn't there any problem ?

I think we should remove --fsync-interval and --reply-fsync, and just
have a --synchronous option, which would imply the same behavior you get
with --fsync-interval=-1 --reply--fsync.

That leaves the question of whether pg_receivexlog should do fsyncs when
it's not acting as a synchronous standby. There isn't any real need to
do so. In asynchronous mode, there are no guarantees anyway, and even
without an fsync, the OS will eventually flush the data to disk.

But we could do even better than that. It would be best if you didn't
need even the --synchronous flag. The server knows whether the client
is a synchronous standby or not. It could tell the client.

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.

In asynchronous mode, I think there is no problem since the specification is same with release version.

The server knows whether the client is a synchronous standby or not.
It could tell the client.

When notifying the synchronous/asynchronous mode to the client from the server,
do we need to change the format of the Message ?

Yeah. Or rather, add a new message type, to indicate the
synchronous/asynchronous status.

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers