Re: Forget close an open relation in ReorderBufferProcessTXN()
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>
Cc: Japin Li <japinli@hotmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Simon Riggs <simon@2ndquadrant.com>, Marco Nenciarini <marco.nenciarini@2ndquadrant.it>
Date: 2021-04-26T05:04:31Z
Lists: 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.
Commits
-
pgoutput: Fix memory leak due to RelationSyncEntry.map.
- eb89cb43a0d0 14.0 landed
- d2505681211b 13.4 landed