Re: Forget close an open relation in ReorderBufferProcessTXN()
От | Amit Kapila |
---|---|
Тема | Re: Forget close an open relation in ReorderBufferProcessTXN() |
Дата | |
Msg-id | CAA4eK1LCgjjq3b8q35B4nCtrhYLBKTh0_tCWH_GTOi0ScQuCNA@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Forget close an open relation in ReorderBufferProcessTXN() ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>) |
Ответы |
RE: Forget close an open relation in ReorderBufferProcessTXN()
|
Список | 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 по дате отправления: