On Tue, Jun 1, 2021 at 9:53 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, May 31, 2021 at 8:12 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Mon, May 31, 2021 at 6:32 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > >
> > > I missed to do the test for streaming. I will to that tomorrow and reply back.
> >
> > For streaming transactions this issue is not there. Because this
> > problem will only occur if the last change is *SPEC INSERT * and after
> > that there is no other UPDATE/INSERT change because on that change we
> > are resetting the toast table. Now, if the transaction has only *SPEC
> > INSERT* without SPEC CONFIRM or any other INSERT/UPDATE then we will
> > not stream it. And if we get any next INSERT/UPDATE then only we can
> > select this for stream but in that case toast will be reset. So as of
> > today for streaming mode we don't have this problem.
> >
>
> What if the next change is a different SPEC_INSERT
> (REORDER_BUFFER_CHANGE_INTERNAL_SPEC_INSERT)? I think in that case we
> will stream but won't free the toast memory.
But if the next change is again the SPEC INSERT then we will keep the
PARTIAL change flag set and we will not select this transaction for
stream right?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
