From: Chao Li <li.evan.chao@gmail.com>
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_5EBE4929-EA2A-497D-A0B0-09EACF1939AE"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Fix a relcache reference leak in reorderbuffer.c
Message-Id: <7DD65D03-3B5A-43B2-99AD-8E6AF5372BAB@gmail.com>
Date: Tue, 18 Aug 2026 11:51:48 +0800
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/7DD65D03-3B5A-43B2-99AD-8E6AF5372BAB%40gmail.com>
Precedence: bulk


--Apple-Mail=_5EBE4929-EA2A-497D-A0B0-09EACF1939AE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

While working on a feature patch that I=E2=80=99m going to post soon, I =
noticed a small issue in reorderbuffer.c. In the =
REORDER_BUFFER_CHANGE_TRUNCATE branch of ReorderBufferProcessTXN(), some =
opened relations might be skipped without being closed, leading to =
leaked relcache references.

The relevant code is:
```
			relations =3D palloc0_array(Relation, nrelids);
			for (i =3D 0; i < nrelids; i++)
			{
				Oid			relid =3D =
change->data.truncate.relids[i];
				Relation	rel;

				rel =3D RelationIdGetRelation(relid);

				if (!RelationIsValid(rel))
					elog(ERROR, "could not open =
relation with OID %u", relid);

				if (!RelationIsLogicallyLogged(rel))
					continue;   <=3D=3D=3D=3D=3D it =
should close rel before skipping it

				relations[nrelations++] =3D rel;
			}

			/* Apply the truncate. */
			ReorderBufferApplyTruncate(rb, txn, nrelations,
									 =
  relations, change,
									 =
  streaming);

			for (i =3D 0; i < nrelations; i++)
				RelationClose(relations[i]);
```

In the loop, each relation that is appended to relations is closed after =
the loop. However, when RelationIsLogicallyLogged(rel) returns false, =
the relation is skipped without being closed, causing the leak.

The attached patch makes a small fix to close the relation before =
continuing.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/


--Apple-Mail=_5EBE4929-EA2A-497D-A0B0-09EACF1939AE
Content-Disposition: attachment;
	filename=v1-0001-Fix-relcache-reference-leak-when-decoding-TRUNCAT.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="v1-0001-Fix-relcache-reference-leak-when-decoding-TRUNCAT.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=2030a53ee7a12f42181615a61e625596f6dd00014c=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20"Chao=20Li=20(Evan)"=20<lic@highgo.com>=0A=
Date:=20Tue,=2018=20Aug=202026=2011:37:54=20+0800=0ASubject:=20[PATCH=20=
v1]=20Fix=20relcache=20reference=20leak=20when=20decoding=20TRUNCATE=0A=0A=
ReorderBufferProcessTXN()=20opens=20every=20relation=20referenced=20by=20=
a=0ATRUNCATE=20change.=20When=20RelationIsLogicallyLogged()=20returns=20=
false,=0Ait=20skips=20the=20relation=20without=20releasing=20the=20=
reference=20acquired=0Aby=20RelationIdGetRelation().=0A=0AClose=20the=20=
relation=20before=20continuing.=0A=0AAuthor:=20Chao=20Li=20=
<lic@highgo.com>=0A---=0A=20=
src/backend/replication/logical/reorderbuffer.c=20|=203=20+++=0A=201=20=
file=20changed,=203=20insertions(+)=0A=0Adiff=20--git=20=
a/src/backend/replication/logical/reorderbuffer.c=20=
b/src/backend/replication/logical/reorderbuffer.c=0Aindex=20=
6aed6346366..b34ec5f2145=20100644=0A---=20=
a/src/backend/replication/logical/reorderbuffer.c=0A+++=20=
b/src/backend/replication/logical/reorderbuffer.c=0A@@=20-2492,7=20=
+2492,10=20@@=20ReorderBufferProcessTXN(ReorderBuffer=20*rb,=20=
ReorderBufferTXN=20*txn,=0A=20=09=09=09=09=09=09=09=09elog(ERROR,=20=
"could=20not=20open=20relation=20with=20OID=20%u",=20relid);=0A=20=0A=20=09=
=09=09=09=09=09=09if=20(!RelationIsLogicallyLogged(rel))=0A+=09=09=09=09=09=
=09=09{=0A+=09=09=09=09=09=09=09=09RelationClose(rel);=0A=20=09=09=09=09=09=
=09=09=09continue;=0A+=09=09=09=09=09=09=09}=0A=20=0A=20=09=09=09=09=09=09=
=09relations[nrelations++]=20=3D=20rel;=0A=20=09=09=09=09=09=09}=0A--=20=0A=
2.50.1=20(Apple=20Git-155)=0A=0A=

--Apple-Mail=_5EBE4929-EA2A-497D-A0B0-09EACF1939AE--