Re: Forget close an open relation in ReorderBufferProcessTXN() - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Forget close an open relation in ReorderBufferProcessTXN()
Date
Msg-id CAA4eK1LCgjjq3b8q35B4nCtrhYLBKTh0_tCWH_GTOi0ScQuCNA@mail.gmail.com
Whole thread Raw
In response to RE: Forget close an open relation in ReorderBufferProcessTXN()  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Responses RE: Forget close an open relation in ReorderBufferProcessTXN()  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
List pgsql-hackers
On Fri, Apr 23, 2021 at 8:03 PM osumi.takamichi@fujitsu.com
<osumi.takamichi@fujitsu.com> wrote:
>
> On Saturday, April 17, 2021 4:13 PM Amit Kapila <amit.kapila16@gmail.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.



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: TRUNCATE on foreign table
Next
From: Andrey Borodin
Date:
Subject: Re: GISTSTATE is too large