Hi~ > On Sat, Aug 16, 2025 at 12:50 AM Jingtang Zhang <mrdrivingd...@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
