Re: Table refer leak in logical replication

Поиск
Список
Период
Сортировка
Искать
От
Michael Paquier
Тема
Re: Table refer leak in logical replication
Дата
Msg-id
YH1OMHEFKWHSBUKX@paquier.xyz
Ответ на
Список
Дерево обсуждения
Table refer leak in logical replication "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>
RE: Table refer leak in logical replication "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
Re: Table refer leak in logical replication Masahiko Sawada <sawada.mshk@gmail.com>
RE: Table refer leak in logical replication "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Masahiko Sawada <sawada.mshk@gmail.com>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Justin Pryzby <pryzby@telsasoft.com>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
RE: Table refer leak in logical replication "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Amit Kapila <amit.kapila16@gmail.com>
Re: Table refer leak in logical replication Amit Kapila <amit.kapila16@gmail.com>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Amit Kapila <amit.kapila16@gmail.com>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
RE: Table refer leak in logical replication "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
Re: Table refer leak in logical replication Amit Kapila <amit.kapila16@gmail.com>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Amit Kapila <amit.kapila16@gmail.com>
Re: Table refer leak in logical replication Amit Kapila <amit.kapila16@gmail.com>
Re: Table refer leak in logical replication Amit Kapila <amit.kapila16@gmail.com>
Re: Table refer leak in logical replication Amit Langote <amitlangote09@gmail.com>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
Re: Table refer leak in logical replication Amit Kapila <amit.kapila16@gmail.com>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
Re: Table refer leak in logical replication Michael Paquier <michael@paquier.xyz>
RE: Table refer leak in logical replication "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>
On Mon, Apr 19, 2021 at 02:33:10PM +0530, Amit Kapila wrote:
> On Mon, Apr 19, 2021 at 12:32 PM Amit Langote  wrote:
>> FWIW, I agree with fixing this bug of 1375422c in as least scary
>> manner as possible.  Hou-san proposed that we add the ResultRelInfo
>> that apply_handle_{insert|update|delete} initialize themselves to
>> es_opened_result_relations.  I would prefer that only
>> ExecInitResultRelation() add anything to es_opened_result_relations()
>> to avoid future maintenance problems.  Instead, a fix as simple as the
>> Hou-san's proposed fix would be to add a ExecCloseResultRelations()
>> call at the end of each of apply_handle_{insert|update|delete}.
> 
> Yeah, that will work too but might look a bit strange. BTW, how that
> is taken care of for ExecuteTruncateGuts? I mean we do add rels there
> like Hou-San's patch without calling ExecCloseResultRelations, the
> rels are probably closed when we close the relation in worker.c but
> what about memory for the list?

TRUNCATE relies on FreeExecutorState() for that, no?  FWIW, I'd rather
agree to use what has been proposed with es_opened_result_relations
like TRUNCATE does rather than attempt to use ExecInitResultRelation()
combined with potentially asymmetric calls to
ExecCloseResultRelations().
--
Michael
В списке pgsql-hackers по дате отправления
От: Amit Langote
Дата:
От: Amit Kapila
Дата:
FAQ