Re: Table refer leak in logical replication
От | Amit Kapila |
---|---|
Тема | Re: Table refer leak in logical replication |
Дата | |
Msg-id | CAA4eK1+etxD7CYf7eEbOh5S8xEcW1rHZC5jdfp4KAcbBaUZSEA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Table refer leak in logical replication (Amit Langote <amitlangote09@gmail.com>) |
Список | pgsql-hackers |
On Mon, Apr 19, 2021 at 1:51 PM Amit Langote <amitlangote09@gmail.com> wrote: > > On Fri, Apr 16, 2021 at 3:24 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Tue, Apr 06, 2021 at 02:25:05PM +0900, Amit Langote wrote: > > > While updating the patch to do so, it occurred to me that maybe we > > > could move the ExecInitResultRelation() call into > > > create_estate_for_relation() too, in the spirit of removing > > > duplicative code. See attached updated patch. Actually I remember > > > proposing that as part of the commit you shared in your earlier email, > > > but for some reason it didn't end up in the commit. I now think maybe > > > we should do that after all. > > > > So, I have been studying 1375422c and this thread. Using > > ExecCloseRangeTableRelations() when cleaning up the executor state is > > reasonable as of the equivalent call to ExecInitRangeTable(). Now, > > there is something that itched me quite a lot while reviewing the > > proposed patch: ExecCloseResultRelations() is missing, but other > > code paths make an effort to mirror any calls of ExecInitRangeTable() > > with it. Looking closer, I think that the worker code is actually > > confused with the handling of the opening and closing of the indexes > > needed by a result relation once you use that, because some code paths > > related to tuple routing for partitions may, or may not, need to do > > that. However, once the code integrates with ExecInitRangeTable() and > > ExecCloseResultRelations(), the index handlings could get much simpler > > to understand as the internal apply routines for INSERT/UPDATE/DELETE > > have no need to think about the opening or closing them. Well, > > mostly, to be honest. > > To bring up another point, if we were to follow the spirit of the > recent c5b7ba4e67a, whereby we moved ExecOpenIndices() from > ExecInitModifyTable() into ExecInsert() and ExecUpdate(), that is, > from during the initialization phase of an INSERT/UPDATE to its actual > execution, we could even consider performing Exec{Open|Close}Indices() > for a replication target relation in > ExecSimpleRelation{Insert|Update}. The ExecOpenIndices() performed in > worker.c is pointless in some cases, for example, when > ExecSimpleRelation{Insert|Update} end up skipping the insert/update of > a tuple due to BR triggers. > Yeah, that is also worth considering and sounds like a good idea. But, as I mentioned before it might be better to consider this separately. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: