On Fri, Jul 24, 2020 at 7:17 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> Your changes look fine to me. Additionally, I have changed a test
> case of getting the streaming changes in 0002. Instead of just
> showing the count, I am showing that the transaction is actually
> streaming.
>
If you want to show the changes then there is no need to display 157
rows probably a few (10-15) should be sufficient. If we can do that
by increasing the size of the row then good, otherwise, I think it is
better to retain the test to display the count.
Today, I have again looked at the first patch
(v42-0001-Extend-the-logical-decoding-output-plugin-API-wi) and didn't
find any more problems with it so planning to commit the same unless
you or someone else want to add more to it. Just for ease of others,
"the next patch extends the logical decoding output plugin API with
stream methods". It adds seven methods to the output plugin API,
adding support for streaming changes for large in-progress
transactions. The methods are stream_start, stream_stop, stream_abort,
stream_commit, stream_change, stream_message, and stream_truncate.
Most of this is a simple extension of the existing methods, with the
semantic difference that the transaction (or subtransaction) is
incomplete and may be aborted later (which is something the regular
API does not really need to deal with).
This also extends the 'test_decoding' plugin, implementing these new
stream methods. The stream_start/start_stop are used to demarcate a
chunk of changes streamed for a particular toplevel transaction.
This commit simply adds these new APIs and the upcoming patch to
"allow the streaming mode in ReorderBuffer" will use these APIs.
--
With Regards,
Amit Kapila.
