RE: [HACKERS] logical decoding of two-phase transactions

Hi, Amit-San

On Thursday, Dec 24, 2020 2:35 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Wed, Dec 23, 2020 at 3:08 PM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
> >
> > > Can you please update the patch for the points we agreed upon?
> >
> > Changed and attached.
> >
>
> Thanks, I have looked at these patches again and it seems patches 0001 to
> 0004 are in good shape, and among those
> v33-0001-Extend-the-output-plugin-API-to-allow-decoding-o is good to go.
> So, I am planning to push the first patch (0001*) in next week sometime
> unless you or someone else has any comments on it.
I agree this from the perspective of good code quality for memory management.

I reviewed the v33 patchset by using valgrind and
conclude that the patchset of version 33th has no problem in terms of memory management.
This can be applied to v34 because the difference between the two versions are really small.

I conducted comparison of valgrind logfiles between master and master with v33 patchset applied.
I checked both testing of contrib/test-decoding and src/test/subscription of course, using valgrind.

The first reason why I reached the conclusion is that
I don't find any description of memcheck error in the log files.
I picked up and greped error message expressions in the documentation of the valgrind - [1],
but there was no grep matches.

Secondly, I surveyed function stack of valgrind's 3 types of memory leak,
"Definitely lost", "Indirectly lost" and "Possibly lost" and
it turned out that the patchset didn't add any new cause of memory leak.

[1] - https://valgrind.org/docs/manual/mc-manual.html#mc-manual.errormsgs

Best Regards,
Takamichi Osumi