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. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
