Memory leak of SMgrRelation object on standby

From: Jingtang Zhang <mrdrivingduck(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Memory leak of SMgrRelation object on standby
Date: 2025-08-15 12:50:20
Message-ID: 28C687D4-F335-417E-B06C-6612A0BD5A10@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi~ hackers

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.

Startup process of standby will redo table dropping with DropRelationFiles,
using smgrdounlinkall to drop buffers and unlink physical files, and then
uses smgrclose to destroy the SMgrRelation object. I think it should use
smgrdestroy here, or the object memory will be leaked.

With concurrent clients, the following pgbench script will produce the
memory leak of a standby startup process easily. Entries will be entered
into the hashtable but never removed.

pgbench -f bench.sql -n -c 32 -j 32 -T 600

```sql
DROP TABLE IF EXISTS tbl:client_id;
CREATE TABLE tbl:client_id (id int);
```

The attached patch export smgrdestroy as a public function, and use it in
DropRelationFiles.


Regards, Jingtang

Attachment Content-Type Size
v1-0001-Fix-SMgrRelation-object-memory-leak-in-DropRelationF.patch application/octet-stream 2.0 KB
unknown_filename text/plain 3 bytes

Browse pgsql-hackers by date

  From Date Subject
Next Message Burd, Greg 2025-08-15 13:58:09 Re: [PATCH] bms_prev_member() can read beyond the end of the array of allocated words
Previous Message Alvaro Herrera 2025-08-15 12:48:17 Re: Adding REPACK [concurrently]