Re: Table refer leak in logical replication

On Tue, Apr 20, 2021 at 02:48:35PM +0900, Amit Langote wrote:
> Manipulating the contents of es_opened_result_relations directly in
> worker.c is admittedly a "hack", which I am reluctant to have other
> places participating in. As originally designed, that list is to
> speed up ExecCloseResultRelations(), not as a place to access result
> relations from. The result relations targeted over the course of
> execution of a query (update/delete) or a (possibly multi-tuple in the
> future) replication apply operation will not be guaranteed to be added
> to the list in any particular order, so assuming where a result
> relation of interest can be found in the list is bound to be unstable.

I really hope that this code gets heavily reorganized before
considering more features or more manipulations of dependencies within
the relations used for any apply operations. From what I can
understand, I think that it would be really nicer and less bug prone
to have a logic like COPY FROM, where we'd rely on a set of
ExecInitResultRelation() with one final ExecCloseResultRelations(),
and as bonus it should be possible to not have to do any business with
ExecOpenIndices() or ExecCloseIndices() as part of worker.c. Anyway,
I also understand that we do with what we have now in this code, so I
am fine to live with this patch as of 14.
--
Michael