Re: Forget close an open relation in ReorderBufferProcessTXN()

On Fri, Apr 23, 2021 at 8:03 PM osumi(dot)takamichi(at)fujitsu(dot)com
<osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
>
> On Saturday, April 17, 2021 4:13 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > I also don't find a test for this. It is introduced in 5dfd1e5a6696,
> > > wrote by Simon Riggs, Marco Nenciarini and Peter Eisentraut. Maybe
> > > they can explain when we can enter this condition?
> >
> > My guess is that this has been copied from the code a few lines above to
> > handle insert/update/delete where it is required to handle some DDL ops like
> > Alter Table but I think we don't need it here (for Truncate op). If that
> > understanding turns out to be true then we should either have an Assert for
> > this or an elog message.
> In this thread, we are discussing 3 topics below...
>
> (1) necessity of the check for REORDER_BUFFER_CHANGE_TRUNCATE in ReorderBufferProcessTXN()
> (2) discussion of whether we disallow decoding of operations on user catalog tables or not
> (3) memory leak of maybe_send_schema() (patch already provided)
>
> Let's address those one by one.
> In terms of (1), which was close to the motivation of this thread,
>

I think (1) and (2) are related because if we need (2) then the check
removed by (1) needs to be replaced with another check. So, I am not
sure how to make this decision.

--
With Regards,
Amit Kapila.