Re: Memory leak of SMgrRelation object on standby

From: Jingtang Zhang <mrdrivingduck(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Memory leak of SMgrRelation object on standby
Date: 2025-08-21 15:07:05
Message-ID: 35DE93ED-1D21-40CE-BD16-141235B7B405@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi~

> On Sat, Aug 16, 2025 at 12:50 AM Jingtang Zhang <mrdrivingduck(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-08-21 15:17:44 Re: Weird error message from Postgres 18
Previous Message Ranier Vilela 2025-08-21 14:25:38 Weird error message from Postgres 18