On Tue, May 26, 2020 at 2:44 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Tue, May 26, 2020 at 10:27 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > >
> > > 2. There is a bug fix in handling the stream abort in 0008 (earlier it
> > > was 0006).
> > >
> >
> > The code changes look fine but it is not clear what was the exact
> > issue. Can you explain?
>
> Basically, in case of an empty subtransaction, we were reading the
> subxacts info but when we could not find the subxid in the subxacts
> info we were not releasing the memory. So on next subxact_info_read
> it will expect that subxacts should be freed but we did not free it in
> that !found case.
>
Okay, on looking at it again, the same code exists in
subxact_info_write as well. It is better to have a function for it.
Can we have a structure like SubXactContext for all the variables used
for subxact? As mentioned earlier I find the allocation/deallocation
of subxacts a bit ad-hoc, so there will always be a chance that we can
forget to free it. Having it allocated in memory context which we can
reset later might reduce that risk. One idea could be that we have a
special memory context for start and stop messages which can be used
to allocate the subxacts there. In case of commit/abort, we can allow
subxacts information to be allocated in ApplyMessageContext which is
reset at the end of each protocol message.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com