Re: Table refer leak in logical replication
От | Amit Kapila |
---|---|
Тема | Re: Table refer leak in logical replication |
Дата | |
Msg-id | CAA4eK1KiMe3=b3cS_Mn2Lnbpo1QRDmbJZap6saz+85zpTv4UtA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Table refer leak in logical replication (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-hackers |
On Mon, Apr 19, 2021 at 5:20 PM Michael Paquier <michael@paquier.xyz> wrote: > > 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? > It is one change for Insert/UpdateDelete. See apply_dispatch() for different change messages. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: