On Tue, May 26, 2020 at 4:46 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Tue, May 26, 2020 at 2:44 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > On Tue, May 26, 2020 at 10:27 AM Amit Kapila <amit.kapil...@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.
Changed as per this. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com