Re: Table refer leak in logical replication
От | Michael Paquier |
---|---|
Тема | Re: Table refer leak in logical replication |
Дата | |
Msg-id | YH1ufTvJKsDvAP7y@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Table refer leak in logical replication (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: Table refer leak in logical replication
|
Список | pgsql-hackers |
On Mon, Apr 19, 2021 at 08:09:05PM +0900, Amit Langote wrote: > On Mon, Apr 19, 2021 at 7:00 PM Amit Kapila <amit.kapila16@gmail.com> wrote: >> It seems like the memory will be freed after we apply the truncate >> because we reset the ApplyMessageContext after applying each message, >> so maybe we don't need to bother about it. > > Yes, ApplyMessageContext seems short-lived enough for this not to > matter. In the case of ExecuteTruncateGuts(), it's PortalContext, but > we don't seem to bother about leaking into that one too. Sorry for the dump question because I have not studied this part of the code in any extensive way, but how many changes at maximum can be applied within a single ApplyMessageContext? I am wondering if we could run into problems depending on the number of relations touched within a single message, or if there are any patches that could run into problems because of this limitation, meaning that we may want to add a proper set of comments within this area to document the limitations attached to a DML operation applied. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: