On Wed, Aug 6, 2014 at 2:34 PM, <furuyao@pm.nttdata.co.jp> wrote:
>> >> I have improved the patch by making following changes:
>> >>
>> >> 1. Since stream_stop() was redundant, stream_stop() at the time of
>> WAL file closing was deleted.
>> >>
>> >> 2. Change the Flash judging timing for the readability of source code.
>> >> I have changed the Flash judging timing , from the continuous
>> message after receiving to
>> >> before the feedbackmassege decision of continue statement after
>> execution.
>> >
>> > Thanks for the updated version of the patch!
>> >
>> > While reviewing the patch, I found that HandleCopyStream() is still
>> > long and which decreases the readability of the source code.
>> > So I feel inclined to refactor the HandleCopyStream() more for better
>> > readability. What about the attached refactoring patch?
>>
>> Sorry, I forgot to attached the patch in previous email. So attached.
>
> Thank you for the refactoring patch.
> I did a review of the patch.
>
> - break; /* ignore the rest of this XLogData packet */
>
> + return true; /* ignore the rest of this XLogData packet */
>
> For break statement at close of wal file, it is a return to true.
> It may be a behavior of continue statement. Is it satisfactory?
Sorry I failed to see your point.
In the original code, when we reach the end of WAL file and it's streaming
stopping point, we break out of inner loop in the code block for processing
XLogData packet. And then we goes back to top of outer loop in
HandleCopyStream. ISTM that the refactored code also works the same way.
Anyway, could you elaborate the problem?
> The walreceiver distributes XLogWalRcvProcessMsg and XLogWalRcvWrite, but isn't that division necessary?
Not necessary, but I have no objection to the idea.
Regards,
--
Fujii Masao
