Re: Memory leak of SMgrRelation object on standby
От | Jingtang Zhang |
---|---|
Тема | Re: Memory leak of SMgrRelation object on standby |
Дата | |
Msg-id | 35DE93ED-1D21-40CE-BD16-141235B7B405@gmail.com обсуждение исходный текст |
Ответ на | Re: Memory leak of SMgrRelation object on standby (Thomas Munro <thomas.munro@gmail.com>) |
Список | pgsql-hackers |
Hi~ > On Sat, Aug 16, 2025 at 12:50 AM Jingtang Zhang <mrdrivingduck@gmail.com> wrote: >> Back to v17, commit 21d9c3ee gave SMgrRelation a well-defined lifetime, and >> smgrclose nolonger removes SMgrRelation object from the hashtable, leaving >> the work to smgrdestroyall. But I find a place that relies on the removing >> behavior previously, but is still calling smgrclose. Also, in this situation, should startup process be treated as a background worker similar to bgwriter/checkpointer and call smgrdestroyall in some period? Even if startup process begins to call smgrdestroy inside DropRelationFiles, suppose, there are a lot of transactions keep creating tables on primary, the startup process of standby will open and create but do not have any chance to destroy a SMgrRelation object, so the memory will always grow. It seems to be true even if smgrclose is responsible for destroying the object previously, because I can't find any smgrclose during WAL recovery, except for DROP DATABASE which is rarely used in production. — Regards, Jingtang
В списке pgsql-hackers по дате отправления: