Re: Decoding speculative insert with toast leaks memory - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Decoding speculative insert with toast leaks memory
Date
Msg-id CAA4eK1JbvGG56Av4GSnR99R2TPQJ7eaA0URu+R45Dyd==nP4hA@mail.gmail.com
Whole thread Raw
In response to Re: Decoding speculative insert with toast leaks memory  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Decoding speculative insert with toast leaks memory
List pgsql-hackers
On Wed, Jun 23, 2021 at 8:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> > While rebasing a patch broken by 4daa140a2f5, I noticed that the patch
> > does this:
>
> > @@ -63,6 +63,7 @@ enum ReorderBufferChangeType
> >         REORDER_BUFFER_CHANGE_INTERNAL_TUPLECID,
> >         REORDER_BUFFER_CHANGE_INTERNAL_SPEC_INSERT,
> >         REORDER_BUFFER_CHANGE_INTERNAL_SPEC_CONFIRM,
> > +       REORDER_BUFFER_CHANGE_INTERNAL_SPEC_ABORT,
> >         REORDER_BUFFER_CHANGE_TRUNCATE
> >  };
>
> > Isn't that an undesirable ABI break for extensions?
>
> I think it's OK in HEAD.  I agree we shouldn't do it like that
> in the back branches.
>

Okay, I'll change this in back branches and HEAD to keep the code
consistent, or do you think it is better to retain the order in HEAD
as it is and just change it for back-branches?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety
Next
From: Zhihong Yu
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety