pg_receivexlog add synchronous mode

Hi,

On 2014-06-05 17:09:44 +0900, furuyao@pm.nttdata.co.jp wrote:

Synchronous(synchronous_commit = on) mode offers the ability to confirm WAL have been streamed in the same way as synchronous replication.
If an output is used as a different disk from the directory where the transaction log should be stored.
Prevent the loss of data due to disk failure.

the additional parameter(-m) and replicationslot specify, that its synchronous mode.
All received WAL write after, flush is executed and reply flush
position.

What's the usecase for this? I can see some benefit in easier testing of
syncrep, but that's basically it?

Flush is not performed every time write, it is performed collectively
like walrecever.

I only glanced at this, but afaics you're only flushing at the end every
WAL segment. That will result in absolutely horrible performance, right?
Walreceiver does flush more frequently than that. It basically syncs
every chunk of received WAL...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

-----Original Message-----
Hi,

On 2014-06-05 17:09:44 +0900, furuyao@pm.nttdata.co.jp wrote:

Synchronous(synchronous_commit = on) mode offers the ability to

confirm WAL have been streamed in the same way as synchronous
replication.

If an output is used as a different disk from the directory where the

transaction log should be stored.

Prevent the loss of data due to disk failure.

the additional parameter(-m) and replicationslot specify, that its

synchronous mode.

All received WAL write after, flush is executed and reply flush
position.

What's the usecase for this? I can see some benefit in easier testing
of syncrep, but that's basically it?

When used with syncrep, standby server crashes, multiplexing of WAL can be collateral.
Data loss can be to nearly zero.

Flush is not performed every time write, it is performed collectively
like walrecever.

I only glanced at this, but afaics you're only flushing at the end every
WAL segment. That will result in absolutely horrible performance, right?
Walreceiver does flush more frequently than that. It basically syncs
every chunk of received WAL...

IMO the completion of the write loop was completion of received WAL.
And Walreceiver same.

I confirm it about the flush position.

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

-----Original Message-----

Flush is not performed every time write, it is performed
collectively like walrecever.

I only glanced at this, but afaics you're only flushing at the end
every WAL segment. That will result in absolutely horrible performance,

right?

Walreceiver does flush more frequently than that. It basically syncs
every chunk of received WAL...

IMO the completion of the write loop was completion of received WAL.
And Walreceiver same.

I confirm it about the flush position.

As you say,Walreceiver does flush more frequently than that.
However, it seems difficult to apply as same way.
So, I have tried a different approach.

1. select () time-out 100msec setting.
2. flush check is time-out of the select ().
3. wirte() only when flush.

I think this is what cause the problem, but I don't have some good idea to solve it.
Can someone please advise me?

Regards,

--
Furuya Osamu

On Fri, Jun 6, 2014 at 8:05 PM, <furuyao@pm.nttdata.co.jp> wrote:

-----Original Message-----

Flush is not performed every time write, it is performed
collectively like walrecever.

I only glanced at this, but afaics you're only flushing at the end
every WAL segment. That will result in absolutely horrible performance,

right?

Walreceiver does flush more frequently than that. It basically syncs
every chunk of received WAL...

IMO the completion of the write loop was completion of received WAL.
And Walreceiver same.

I confirm it about the flush position.

As you say,Walreceiver does flush more frequently than that.

No. IIUC walreceiver does flush *less* frequently than what you implemented
on pg_receivexlog. Your version of pg_receivexlog tries to do flush every time
when it receives one WAL chunk. OTOH, walreceiver does flush only when
there is no extra WAL chunk in receive buffer. IOW, after writing WAL chunk,
if there is another WAL chunk that walreceiver can receive immediately, it
postpones flush later.

However, it seems difficult to apply as same way.

Why? ISTM that's not so difficult.

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

No. IIUC walreceiver does flush *less* frequently than what you
implemented on pg_receivexlog. Your version of pg_receivexlog tries to
do flush every time when it receives one WAL chunk. OTOH, walreceiver
does flush only when there is no extra WAL chunk in receive buffer. IOW,
after writing WAL chunk, if there is another WAL chunk that walreceiver
can receive immediately, it postpones flush later.

However, it seems difficult to apply as same way.

Why? ISTM that's not so difficult.

I was not able to understand movement of walreceiver well.
While walreceiver writes data, do PQconsumeInput() by omitting the select().
Do flush if the PQgetCopyData has been to return the zero continuously.
Fixed to the same process using the flag.

Regards,

--
Furuya Osamu

On Tue, Jun 10, 2014 at 5:01 PM, <furuyao@pm.nttdata.co.jp> wrote:

No. IIUC walreceiver does flush *less* frequently than what you
implemented on pg_receivexlog. Your version of pg_receivexlog tries to
do flush every time when it receives one WAL chunk. OTOH, walreceiver
does flush only when there is no extra WAL chunk in receive buffer. IOW,
after writing WAL chunk, if there is another WAL chunk that walreceiver
can receive immediately, it postpones flush later.

However, it seems difficult to apply as same way.

Why? ISTM that's not so difficult.

I was not able to understand movement of walreceiver well.
While walreceiver writes data, do PQconsumeInput() by omitting the select().
Do flush if the PQgetCopyData has been to return the zero continuously.
Fixed to the same process using the flag.

You introduced the state machine using the flag "flush_flg" into pg_receivexlog.
That's complicated and would reduce the readability of the source code. I think
that the logic should be simpler like walreceiver's one.

Maybe I found one problematic path as follows:

1. WAL is written and flush_flag is set to 1
2. PQgetCopyData() returns 0 and flush_flg is incremented to 2
3. PQconsumeInput() is executed
4. PQgetCopyData() reads keepalive message
5. After processing keepalive message, PQgetCopyDate() returns 0
6. Since flush_flg is 2, WAL is flushed and flush_flg is reset to 0

But new message can arrive while processing keepalive message. Before
flushing WAL, such new message should be processed.

+        Enables synchronous mode. If replication slot is disabled then
+        this setting is irrelevant.

Why is that irrelevant in that case?

Even when replication slot is not used, thanks to this feature, pg_receivexlog
can flush WAL more proactively and which may improve the durability of WAL
which pg_receivexlog writes.

+ printf(_(" -m, --sync-mode synchronous mode\n"));

I think that calling this feature "synchronous mode" is confusing.

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

You introduced the state machine using the flag "flush_flg" into
pg_receivexlog.
That's complicated and would reduce the readability of the source code.
I think that the logic should be simpler like walreceiver's one.

Maybe I found one problematic path as follows:

1. WAL is written and flush_flag is set to 1 2. PQgetCopyData() returns
0 and flush_flg is incremented to 2 3. PQconsumeInput() is executed 4.
PQgetCopyData() reads keepalive message 5. After processing keepalive
message, PQgetCopyDate() returns 0 6. Since flush_flg is 2, WAL is
flushed and flush_flg is reset to 0

But new message can arrive while processing keepalive message. Before
flushing WAL, such new message should be processed.

Together with the readability, fixed to the same process as the loop of walreceiver.

+        Enables synchronous mode. If replication slot is disabled then
+        this setting is irrelevant.

Why is that irrelevant in that case?

Even when replication slot is not used, thanks to this feature,
pg_receivexlog can flush WAL more proactively and which may improve the
durability of WAL which pg_receivexlog writes.

It's mean, report the flush position or not.
If the SLOT is not used, it is not reported.
Fixed to be reported only when using the SLOT.

+ printf(_(" -m, --sync-mode synchronous mode\n"));

I think that calling this feature "synchronous mode" is confusing.

Modified the "synchronous mode" to "this mode is written some records, flush them to disk.".

Regards,

--
Furuya Osamu

On Mon, Jun 16, 2014 at 7:03 PM, <furuyao@pm.nttdata.co.jp> wrote:

You introduced the state machine using the flag "flush_flg" into
pg_receivexlog.
That's complicated and would reduce the readability of the source code.
I think that the logic should be simpler like walreceiver's one.

Maybe I found one problematic path as follows:

1. WAL is written and flush_flag is set to 1 2. PQgetCopyData() returns
0 and flush_flg is incremented to 2 3. PQconsumeInput() is executed 4.
PQgetCopyData() reads keepalive message 5. After processing keepalive
message, PQgetCopyDate() returns 0 6. Since flush_flg is 2, WAL is
flushed and flush_flg is reset to 0

But new message can arrive while processing keepalive message. Before
flushing WAL, such new message should be processed.

Together with the readability, fixed to the same process as the loop of walreceiver.

+        Enables synchronous mode. If replication slot is disabled then
+        this setting is irrelevant.

Why is that irrelevant in that case?

Even when replication slot is not used, thanks to this feature,
pg_receivexlog can flush WAL more proactively and which may improve the
durability of WAL which pg_receivexlog writes.

It's mean, report the flush position or not.
If the SLOT is not used, it is not reported.
Fixed to be reported only when using the SLOT.

+ printf(_(" -m, --sync-mode synchronous mode\n"));

I think that calling this feature "synchronous mode" is confusing.

Modified the "synchronous mode" to "this mode is written some records, flush them to disk.".

I found that this patch breaks --status-interval option of pg_receivexlog
when -m option which the patch introduced is supplied. When -m is set,
pg_receivexlog tries to send the feedback message as soon as it flushes
WAL file even if status interval timeout has not been passed yet. If you
want to send the feedback as soon as WAL is written or flushed, like
walreceiver does, you need to extend --status-interval option, for example,
so that it accepts the value "-1" which means enabling that behavior.

Including this change in your original patch would make it more difficult
to review. I think that you should implement this as separate patch.
Thought?

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 found that this patch breaks --status-interval option of
pg_receivexlog when -m option which the patch introduced is supplied.
When -m is set, pg_receivexlog tries to send the feedback message as soon
as it flushes WAL file even if status interval timeout has not been passed
yet. If you want to send the feedback as soon as WAL is written or flushed,
like walreceiver does, you need to extend --status-interval option, for
example, so that it accepts the value "-1" which means enabling that
behavior.

Including this change in your original patch would make it more difficult
to review. I think that you should implement this as separate patch.
Thought?

As your comments, the current specification to ignore the --status-intarvall.
It is necessary to respond immediately to synchronize.

It is necessary to think about specifications the --status-intarvall.
So I revised it to a patch of flushmode which performed flush by a timing same as walreceiver.

A changed part deletes the feedback message after flush, and transmitted the feedback message according to the status interval.
Change to flushmode from syncmode the mode name, and fixed the document.

Regards,

--
Furuya Osamu

On Tue, Jun 24, 2014 at 3:18 PM, <furuyao@pm.nttdata.co.jp> wrote:

I found that this patch breaks --status-interval option of
pg_receivexlog when -m option which the patch introduced is supplied.
When -m is set, pg_receivexlog tries to send the feedback message as soon
as it flushes WAL file even if status interval timeout has not been passed
yet. If you want to send the feedback as soon as WAL is written or flushed,
like walreceiver does, you need to extend --status-interval option, for
example, so that it accepts the value "-1" which means enabling that
behavior.

Including this change in your original patch would make it more difficult
to review. I think that you should implement this as separate patch.
Thought?

As your comments, the current specification to ignore the --status-intarvall.
It is necessary to respond immediately to synchronize.

It is necessary to think about specifications the --status-intarvall.
So I revised it to a patch of flushmode which performed flush by a timing same as walreceiver.

I'm not sure if it's good idea to call the feature which you'd like to
add as 'flush mode'.
ISTM that 'flush mode' is vague and confusion for users. Instead, what
about adding
something like --fsync-interval which pg_recvlogical supports?

A changed part deletes the feedback message after flush, and transmitted the feedback message according to the status interval.
Change to flushmode from syncmode the mode name, and fixed the document.

+ * Receive a message available from XLOG stream, blocking for
+ * maximum of 'timeout' ms.

The above comment seems incorrect because 'timeout' is boolean argument.

+            FD_ZERO(&input_mask);
+            FD_SET(PQsocket(conn), &input_mask);
+            if (standby_message_timeout)

Why did you get rid of the check of 'still_sending' flag here? Originally the
flag was checked but not in the patch.

+ r = rcv_receive(true , &copybuf, conn,
standby_message_timeout, last_status, now);

When the return value is -2 (i.e., an error happend), we should go to
the 'error' label.

ISTM that stream_stop() should be called every time a message is
processed. But the
patch changes pg_receivexlog so that it keeps processing the received
data without
calling stream_stop(). This seems incorrect.

'copybuf' needs to be free'd every time new message is received. But you seem to
have forgotten to do that when rcv_receive() with no timeout is called.

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

On Wed, Jun 25, 2014 at 3:50 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Tue, Jun 24, 2014 at 3:18 PM, <furuyao@pm.nttdata.co.jp> wrote:

I found that this patch breaks --status-interval option of
pg_receivexlog when -m option which the patch introduced is supplied.
When -m is set, pg_receivexlog tries to send the feedback message as soon
as it flushes WAL file even if status interval timeout has not been passed
yet. If you want to send the feedback as soon as WAL is written or flushed,
like walreceiver does, you need to extend --status-interval option, for
example, so that it accepts the value "-1" which means enabling that
behavior.

Including this change in your original patch would make it more difficult
to review. I think that you should implement this as separate patch.
Thought?

As your comments, the current specification to ignore the --status-intarvall.
It is necessary to respond immediately to synchronize.

It is necessary to think about specifications the --status-intarvall.
So I revised it to a patch of flushmode which performed flush by a timing same as walreceiver.

I'm not sure if it's good idea to call the feature which you'd like to
add as 'flush mode'.
ISTM that 'flush mode' is vague and confusion for users. Instead, what
about adding
something like --fsync-interval which pg_recvlogical supports?

A changed part deletes the feedback message after flush, and transmitted the feedback message according to the status interval.
Change to flushmode from syncmode the mode name, and fixed the document.

+ * Receive a message available from XLOG stream, blocking for
+ * maximum of 'timeout' ms.

The above comment seems incorrect because 'timeout' is boolean argument.

+            FD_ZERO(&input_mask);
+            FD_SET(PQsocket(conn), &input_mask);
+            if (standby_message_timeout)

Why did you get rid of the check of 'still_sending' flag here? Originally the
flag was checked but not in the patch.

+ r = rcv_receive(true , &copybuf, conn,
standby_message_timeout, last_status, now);

When the return value is -2 (i.e., an error happend), we should go to
the 'error' label.

ISTM that stream_stop() should be called every time a message is
processed. But the
patch changes pg_receivexlog so that it keeps processing the received
data without
calling stream_stop(). This seems incorrect.

'copybuf' needs to be free'd every time new message is received. But you seem to
have forgotten to do that when rcv_receive() with no timeout is called.

The patch looks somewhat complicated and bugs can be easily introduced
because it tries to not only add new feature but also reorganize
the main loop in HandleCopyStream at the same time. To keep the patch
simple, I'm thinking to firstly apply the attached patch which just
refactors the main loop. Then we can apply the main patch, i.e., add new
feature. Thought?

Regards,

--
Fujii Masao

The patch looks somewhat complicated and bugs can be easily introduced
because it tries to not only add new feature but also reorganize the main
loop in HandleCopyStream at the same time. To keep the patch simple, I'm
thinking to firstly apply the attached patch which just refactors the
main loop. Then we can apply the main patch, i.e., add new feature.
Thought?

Thank you for the refactoring patch.
I did a review of the patch.
As a result, I found the calculation of sleeptime when the --status-intarvall is set to 1 was incorrect.

--status-intarvall 1 --> sleeptime 1.9999 !?
--status-intarvall 2 --> sleeptime 1.9999 OK
--status-intarvall 3 --> sleeptime 2.9999 OK

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 Thu, Jun 26, 2014 at 7:01 PM, <furuyao@pm.nttdata.co.jp> wrote:

The patch looks somewhat complicated and bugs can be easily introduced
because it tries to not only add new feature but also reorganize the main
loop in HandleCopyStream at the same time. To keep the patch simple, I'm
thinking to firstly apply the attached patch which just refactors the
main loop. Then we can apply the main patch, i.e., add new feature.
Thought?

Thank you for the refactoring patch.
I did a review of the patch.
As a result, I found the calculation of sleeptime when the --status-intarvall is set to 1 was incorrect.

--status-intarvall 1 --> sleeptime 1.9999 !?
--status-intarvall 2 --> sleeptime 1.9999 OK
--status-intarvall 3 --> sleeptime 2.9999 OK

Thanks for the review!

+            if (secs <= 0)
+                secs = 1;    /* Always sleep at least 1 sec */
+
+            sleeptime = secs * 1000 + usecs / 1000;

The above is the code which caused that problem. 'usecs' should have been
reset to zero when 'secs' are rounded up to 1 second. But not. Attached is
the updated version of the patch.

Regards,

--
Fujii Masao

On 2014-06-05 19:13:34 +0900, furuyao@pm.nttdata.co.jp wrote:

-----Original Message-----
Hi,

On 2014-06-05 17:09:44 +0900, furuyao@pm.nttdata.co.jp wrote:

Synchronous(synchronous_commit = on) mode offers the ability to

confirm WAL have been streamed in the same way as synchronous
replication.

If an output is used as a different disk from the directory where the

transaction log should be stored.

Prevent the loss of data due to disk failure.

the additional parameter(-m) and replicationslot specify, that its

synchronous mode.

All received WAL write after, flush is executed and reply flush
position.

What's the usecase for this? I can see some benefit in easier testing
of syncrep, but that's basically it?

When used with syncrep, standby server crashes, multiplexing of WAL can be collateral.
Data loss can be to nearly zero.

I don't see how this gets pg_receivexlog much closer to a solution for
multiplexing WAL. Since there's no support for streaming data, removing
old WAL and such it seems to me you'd need to have something entirely
different anyway?
I'm not really averse to adding this feature (on the basis of easier
syncrep testing alone), but I don't like the arguments for it so far...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
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!

+            if (secs <= 0)
+                secs = 1;    /* Always sleep at least 1 sec */
+
+            sleeptime = secs * 1000 + usecs / 1000;

The above is the code which caused that problem. 'usecs' should have been
reset to zero when 'secs' are rounded up to 1 second. But not. Attached
is the updated version of the patch.

Thank you for the refactoring v2 patch.
I did a review of the patch.

1. applied cleanly and compilation was without warnings and errors
2. all regress tests was passed ok
3. sleeptime is ok when the --status-intarvall is set to 1

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

Synchronous(synchronous_commit = on) mode offers the ability to

confirm WAL have been streamed in the same way as synchronous
replication.

If an output is used as a different disk from the directory where
the

transaction log should be stored.

Prevent the loss of data due to disk failure.

the additional parameter(-m) and replicationslot specify, that its

synchronous mode.

All received WAL write after, flush is executed and reply flush
position.

What's the usecase for this? I can see some benefit in easier
testing of syncrep, but that's basically it?

When used with syncrep, standby server crashes, multiplexing of WAL

can be collateral.

Data loss can be to nearly zero.

I don't see how this gets pg_receivexlog much closer to a solution for
multiplexing WAL. Since there's no support for streaming data, removing
old WAL and such it seems to me you'd need to have something entirely
different anyway?
I'm not really averse to adding this feature (on the basis of easier
syncrep testing alone), but I don't like the arguments for it so far...

The problems of multiplex WAL which I recognize as follows.

1.To flush multiple records per received consecutively. (implemented in pg_receivexlog)
2.A feedback message reports a flush position for every flush. (implemented in pg_receivexlog)
3.establishment of recovery steps by using pg_receivexlog.
4.removing old WAL.(Remove the recycled or archived WAL)

First, it is not considered multiple WAL.
I will post a patch to flush to multiple records for each received continuously.

By increasing the frequency of flush,
this patch reduces the lost of data of pg_receivexlog machine crash.

I will consider in turn also other problems.

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 Mon, Jun 30, 2014 at 7:09 PM, <furuyao@pm.nttdata.co.jp> wrote:

Thanks for the review!

+            if (secs <= 0)
+                secs = 1;    /* Always sleep at least 1 sec */
+
+            sleeptime = secs * 1000 + usecs / 1000;

The above is the code which caused that problem. 'usecs' should have been
reset to zero when 'secs' are rounded up to 1 second. But not. Attached
is the updated version of the patch.

Thank you for the refactoring v2 patch.
I did a review of the patch.

1. applied cleanly and compilation was without warnings and errors
2. all regress tests was passed ok
3. sleeptime is ok when the --status-intarvall is set to 1

Thanks for reviewing the patch!

I think that this refactoring patch is useful for improving source code
readability and making the future patches simpler, whether we adopt
your patch or not. So, barring any objections, I'm thinking to commit
this refactoring 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

On Tue, Jul 1, 2014 at 10:11 PM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Mon, Jun 30, 2014 at 7:09 PM, <furuyao@pm.nttdata.co.jp> wrote:

Thanks for the review!

+            if (secs <= 0)
+                secs = 1;    /* Always sleep at least 1 sec */
+
+            sleeptime = secs * 1000 + usecs / 1000;

The above is the code which caused that problem. 'usecs' should have been
reset to zero when 'secs' are rounded up to 1 second. But not. Attached
is the updated version of the patch.

Thank you for the refactoring v2 patch.
I did a review of the patch.

1. applied cleanly and compilation was without warnings and errors
2. all regress tests was passed ok
3. sleeptime is ok when the --status-intarvall is set to 1

Thanks for reviewing the patch!

I think that this refactoring patch is useful for improving source code
readability and making the future patches simpler, whether we adopt
your patch or not. So, barring any objections, I'm thinking to commit
this refactoring patch.

Committed!

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 reviewing the patch!

I think that this refactoring patch is useful for improving source
code readability and making the future patches simpler, whether we
adopt your patch or not. So, barring any objections, I'm thinking to
commit this refactoring patch.

Committed!

It is a patch that added the --fsync-interval option.
Interface of --fsync-interval option was referring to the "pg_recvlogical.c".

It is not judgement the flush on a per-message basis.
It is judgment at the time of receipt stop of the message.

If you specify a zero --fsync-interval make the flush at the same timing as the walreceiver .
If you do not specify --fsync-interval, you will flush only when switching as WAL files as in the past.

Regards,

--
Furuya Osamu