Memory leak of SMgrRelation object on standby
Jingtang Zhang <mrdrivingduck@gmail.com>
From: Jingtang Zhang <mrdrivingduck@gmail.com>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>,
pgsql-hackers@lists.postgresql.org
Date: 2025-08-15T12:50:20Z
Lists: pgsql-hackers
Attachments
- v1-0001-Fix-SMgrRelation-object-memory-leak-in-DropRelationF.patch (application/octet-stream) patch v1-0001
- (unnamed) (text/plain)
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
Commits
-
Fix leak with SMgrRelations in startup process
- e2dd7b2acf27 17.7 landed
- 039301b3fceb 18.0 landed
- 8c8f7b199d90 19 (unreleased) landed
-
Give SMgrRelation pointers a well-defined lifetime.
- 21d9c3ee4ef7 17.0 cited