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
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 |