From: Daniel Gustafsson <daniel@yesql.se>
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_89EE57CA-704B-42EC-9174-03867D6FDC16"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Subject: Fix PGresult leak in pg_dump during binary upgrade
Message-Id: <374550C1-F4ED-4D9D-9498-0FD029CCF674@yesql.se>
Date: Wed, 15 May 2024 20:40:43 +0200
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Archived-At: <https://www.postgresql.org/message-id/374550C1-F4ED-4D9D-9498-0FD029CCF674%40yesql.se>
Precedence: bulk


--Apple-Mail=_89EE57CA-704B-42EC-9174-03867D6FDC16
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

While looking at pg_dump performance today I noticed that pg_dump fails =
to
clear query results in binary_upgrade_set_pg_class_oids during binary =
upgrade
mode.  9a974cbcba00 moved the query to the outer block, but left the =
PQclear
and query buffer destruction in the is_index conditional, making it not =
always
be executed.  353708e1fb2d fixed the leak of the query buffer but left =
the
PGresult leak.  The attached fixes the PGresult leak which when =
upgrading large
schemas can be non-trivial.

This needs to be backpatched down to v15.

--
Daniel Gustafsson


--Apple-Mail=_89EE57CA-704B-42EC-9174-03867D6FDC16
Content-Disposition: attachment;
	filename=0001-Fix-query-result-leak-during-binary-upgrade.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="0001-Fix-query-result-leak-during-binary-upgrade.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=206d6f286d62d211e2238948c1ab8d7dd3d5f6c00a=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20Daniel=20Gustafsson=20=
<dgustafsson@postgresql.org>=0ADate:=20Wed,=2015=20May=202024=2020:32:14=20=
+0200=0ASubject:=20[PATCH]=20Fix=20query=20result=20leak=20during=20=
binary=20upgrade=0A=0A9a974cbcba00=20moved=20the=20query=20in=20=
binary_upgrade_set_pg_class_oids=20to=20the=0Aouter=20level,=20but=20=
left=20the=20PQclear=20and=20query=20buffer=20destruction=20in=20the=0A=
is_index=20conditional.=20=20353708e1fb2d=20fixed=20the=20leak=20of=20=
the=20query=20buffer=0Abut=20left=20the=20PGresult=20leak.=20This=20=
moves=20clearing=20the=20result=20to=20the=20outer=0Alevel=20ensuring=20=
that=20it=20will=20be=20called.=0A---=0A=20src/bin/pg_dump/pg_dump.c=20|=20=
4=20++--=0A=201=20file=20changed,=202=20insertions(+),=202=20=
deletions(-)=0A=0Adiff=20--git=20a/src/bin/pg_dump/pg_dump.c=20=
b/src/bin/pg_dump/pg_dump.c=0Aindex=20ac920f64c7..5dfa7b3bcb=20100644=0A=
---=20a/src/bin/pg_dump/pg_dump.c=0A+++=20b/src/bin/pg_dump/pg_dump.c=0A=
@@=20-5479,8=20+5479,6=20@@=20binary_upgrade_set_pg_class_oids(Archive=20=
*fout,=0A=20=09=09=09=09=09=09=09=20=20"SELECT=20=
pg_catalog.binary_upgrade_set_next_index_relfilenode('%u'::pg_catalog.oid)=
;\n",=0A=20=09=09=09=09=09=09=09=20=20toast_index_relfilenumber);=0A=20=09=
=09}=0A-=0A-=09=09PQclear(upgrade_res);=0A=20=09}=0A=20=09else=0A=20=09{=0A=
@@=20-5493,6=20+5491,8=20@@=20binary_upgrade_set_pg_class_oids(Archive=20=
*fout,=0A=20=09=09=09=09=09=09=20=20relfilenumber);=0A=20=09}=0A=20=0A+=09=
PQclear(upgrade_res);=0A+=0A=20=09appendPQExpBufferChar(upgrade_buffer,=20=
'\n');=0A=20=0A=20=09destroyPQExpBuffer(upgrade_query);=0A--=20=0A2.39.3=20=
(Apple=20Git-146)=0A=0A=

--Apple-Mail=_89EE57CA-704B-42EC-9174-03867D6FDC16--