MIME-Version: 1.0
From: Baji Shaik <baji.pgdev@gmail.com>
Date: Fri, 5 Jun 2026 12:44:24 -0500
Message-ID: 
 <CA+fm-RMopta1Dmq8udiU5sp+zwTvhUf4+xfbr3rZDfczH+p-xw@mail.gmail.com>
Subject: [PATCH] Fix memory leak in pgstat_progress_parallel_incr_param()
To: pgsql-hackers@lists.postgresql.org
Cc: bertranddrouvot.pg@gmail.com
Content-Type: multipart/mixed; boundary="000000000000ea501a06538536b3"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2Bfm-RMopta1Dmq8udiU5sp%2BzwTvhUf4%2Bxfbr3rZDfczH%2Bp-xw%40mail.gmail.com>
Precedence: bulk

--000000000000ea501a06538536b3
Content-Type: multipart/alternative; boundary="000000000000ea501906538536b1"

--000000000000ea501906538536b1
Content-Type: text/plain; charset="UTF-8"

Hi,

While running parallel vacuum with track_cost_delay_timing=on, I
noticed memory in the parallel worker process keeps growing
proportionally to vacuum runtime, and is never reclaimed until the
worker exits.

I think pgstat_progress_parallel_incr_param() (backend_progress.c)
leaks memory on every call from a parallel worker.

The suspected block:

    static StringInfoData progress_message;
    initStringInfo(&progress_message);                /* palloc -> A   */
    pq_beginmessage(&progress_message, PqMsg_Progress);
    /* pq_beginmessage internally calls initStringInfo again ->
       palloc -> B, A is orphaned                                       */
    pq_sendint32(&progress_message, index);
    pq_sendint64(&progress_message, incr);
    pq_endmessage(&progress_message);                 /* pfree(B), A leaked
*/

So one palloc(~1 kB) leaks per call, into the per-worker context.

This is an oversight of f1889729dd3 ("Add new parallel message type
to progress reporting"); track_cost_delay_timing just makes it more
visible.  With that GUC enabled, a long-running parallel vacuum leaks
megabytes per worker (~232 MB observed in a 43-min vacuum at default
settings on a 15M-row, 30-index workload).

The proposed fix is in the attached patch which does a one-time init of the
static
buffer, then pq_beginmessage_reuse() / pq_endmessage_reuse() so the
buffer is allocated once and reused.

All 245 regression tests pass.

Thanks,
Baji Shaik.

--000000000000ea501906538536b1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>While running parallel vacuum with track_cost_d=
elay_timing=3Don, I<br>noticed memory in the parallel worker process keeps =
growing<br>proportionally to vacuum runtime, and is never reclaimed until t=
he<br>worker exits.<br><br>I think pgstat_progress_parallel_incr_param() (b=
ackend_progress.c)<br>leaks memory on every call from a parallel worker.<br=
><br>The suspected block:<br><br>=C2=A0 =C2=A0 static StringInfoData progre=
ss_message;<br>=C2=A0 =C2=A0 initStringInfo(&amp;progress_message); =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* palloc -&gt; A =C2=A0 */=
<br>=C2=A0 =C2=A0 pq_beginmessage(&amp;progress_message, PqMsg_Progress);<b=
r>=C2=A0 =C2=A0 /* pq_beginmessage internally calls initStringInfo again -&=
gt;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0palloc -&gt; B, A is orphaned =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */<br>=C2=A0 =C2=A0 pq_sen=
dint32(&amp;progress_message, index);<br>=C2=A0 =C2=A0 pq_sendint64(&amp;pr=
ogress_message, incr);<br>=C2=A0 =C2=A0 pq_endmessage(&amp;progress_message=
); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* pfree(B), A l=
eaked */<br><br>So one palloc(~1 kB) leaks per call, into the per-worker co=
ntext.<br><br>This is an oversight of f1889729dd3 (&quot;Add new parallel m=
essage type<br>to progress reporting&quot;); track_cost_delay_timing just m=
akes it more<br>visible.=C2=A0 With that GUC enabled, a long-running parall=
el vacuum leaks<br>megabytes per worker (~232 MB observed in a 43-min vacuu=
m at default<br>settings on a 15M-row, 30-index workload).<br><br>The propo=
sed fix is in the attached patch which does a one-time init of the static<b=
r>buffer, then pq_beginmessage_reuse() / pq_endmessage_reuse() so the<br>bu=
ffer is allocated once and reused.<br><br>All 245 regression tests pass.<br=
><br>Thanks,<br>Baji Shaik.</div>

--000000000000ea501906538536b1--

--000000000000ea501a06538536b3
Content-Type: application/octet-stream;
	name="0001-Fix-memory-leak-in-pgstat_progress_parallel_incr_par.patch"
Content-Disposition: attachment;
	filename="0001-Fix-memory-leak-in-pgstat_progress_parallel_incr_par.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mq17pufi0>
X-Attachment-Id: f_mq17pufi0

RnJvbSA1OTA3MTJiNGZlYTM4MWE4MmNmYWE5YWExN2JiZTBmMDdjYTBjMTZhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBCYWppIFNoYWlrIDxiYWppLnBnZGV2QGdtYWlsLmNvbT4KRGF0
ZTogRnJpLCA1IEp1biAyMDI2IDEyOjQwOjE4IC0wNTAwClN1YmplY3Q6IFtQQVRDSF0gRml4IG1l
bW9yeSBsZWFrIGluIHBnc3RhdF9wcm9ncmVzc19wYXJhbGxlbF9pbmNyX3BhcmFtKCkKCldoZW4g
Y2FsbGVkIGZyb20gYSBwYXJhbGxlbCB3b3JrZXIsIHBnc3RhdF9wcm9ncmVzc19wYXJhbGxlbF9p
bmNyX3BhcmFtKCkKY2FsbHMgaW5pdFN0cmluZ0luZm8oKSBvbiBhIHN0YXRpYyBTdHJpbmdJbmZv
RGF0YSBhbmQgdGhlbiBpbW1lZGlhdGVseQpjYWxscyBwcV9iZWdpbm1lc3NhZ2UoKSwgd2hpY2gg
Y2FsbHMgaW5pdFN0cmluZ0luZm8oKSBhZ2Fpbi4gIFRoZSBzZWNvbmQKY2FsbCBvdmVyd3JpdGVz
IGJ1Zi0+ZGF0YSB3aXRoIGEgZnJlc2hseSBwYWxsb2MnZCBidWZmZXIsIG9ycGhhbmluZyB0aGUK
Zmlyc3Qgb25lLiAgcHFfZW5kbWVzc2FnZSgpIHRoZW4gZnJlZXMgb25seSB0aGUgc2Vjb25kIGJ1
ZmZlciwgc28gZWFjaApjYWxsIGxlYWtzIH4xIGtCIGludG8gdGhlIHBlci13b3JrZXIgbWVtb3J5
IGNvbnRleHQuCgpUaGUgbGVhayBpcyBuZWdsaWdpYmxlIGJ5IGRlZmF1bHQsIGJ1dCB3aXRoIHRy
YWNrX2Nvc3RfZGVsYXlfdGltaW5nCmVuYWJsZWQgdGhlIHBhcmFsbGVsIGNvc3QtZGVsYXkgcmVw
b3J0aW5nIHBhdGggZmlyZXMgb25jZSBwZXIgc2Vjb25kIHBlcgp3b3JrZXIsIHNvIGEgbG9uZy1y
dW5uaW5nIHBhcmFsbGVsIHZhY3V1bSBsZWFrcyBtZWdhYnl0ZXMgcGVyIHdvcmtlci4KCkZpeCBi
eSBpbml0aWFsaXppbmcgdGhlIHN0YXRpYyBidWZmZXIgb25jZSBwZXIgcHJvY2VzcyBhbmQgdXNp
bmcKcHFfYmVnaW5tZXNzYWdlX3JldXNlKCkvcHFfZW5kbWVzc2FnZV9yZXVzZSgpLCBzbyB0aGUg
YnVmZmVyIGlzIGFsbG9jYXRlZApvbmNlIGFuZCByZXVzZWQuCgpUaGlzIGlzIGFuIG92ZXJzaWdo
dCBvZiBmMTg4OTcyOWRkMyAoIkFkZCBuZXcgcGFyYWxsZWwgbWVzc2FnZSB0eXBlIHRvCnByb2dy
ZXNzIHJlcG9ydGluZyIpOyB0cmFja19jb3N0X2RlbGF5X3RpbWluZyBqdXN0IG1ha2VzIGl0IG1v
cmUgdmlzaWJsZS4KCkF1dGhvcjogQmFqaSBTaGFpayA8YmFqaS5wZ2RldkBnbWFpbC5jb20+Ci0t
LQogc3JjL2JhY2tlbmQvdXRpbHMvYWN0aXZpdHkvYmFja2VuZF9wcm9ncmVzcy5jIHwgMjAgKysr
KysrKysrKysrKystLS0tLQogMSBmaWxlIGNoYW5nZWQsIDE1IGluc2VydGlvbnMoKyksIDUgZGVs
ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tlbmQvdXRpbHMvYWN0aXZpdHkvYmFja2Vu
ZF9wcm9ncmVzcy5jIGIvc3JjL2JhY2tlbmQvdXRpbHMvYWN0aXZpdHkvYmFja2VuZF9wcm9ncmVz
cy5jCmluZGV4IGIwMzU5NzcxZGU1Li4wNDgzNzQxYTgwZSAxMDA2NDQKLS0tIGEvc3JjL2JhY2tl
bmQvdXRpbHMvYWN0aXZpdHkvYmFja2VuZF9wcm9ncmVzcy5jCisrKyBiL3NyYy9iYWNrZW5kL3V0
aWxzL2FjdGl2aXR5L2JhY2tlbmRfcHJvZ3Jlc3MuYwpAQCAtOTksMTMgKzk5LDIzIEBAIHBnc3Rh
dF9wcm9ncmVzc19wYXJhbGxlbF9pbmNyX3BhcmFtKGludCBpbmRleCwgaW50NjQgaW5jcikKIAlp
ZiAoSXNQYXJhbGxlbFdvcmtlcigpKQogCXsKIAkJc3RhdGljIFN0cmluZ0luZm9EYXRhIHByb2dy
ZXNzX21lc3NhZ2U7Ci0KLQkJaW5pdFN0cmluZ0luZm8oJnByb2dyZXNzX21lc3NhZ2UpOwotCi0J
CXBxX2JlZ2lubWVzc2FnZSgmcHJvZ3Jlc3NfbWVzc2FnZSwgUHFNc2dfUHJvZ3Jlc3MpOworCQlz
dGF0aWMgYm9vbCBwcm9ncmVzc19tZXNzYWdlX2luaXRpYWxpemVkID0gZmFsc2U7CisKKwkJLyoK
KwkJICogSW5pdGlhbGl6ZSB0aGUgbWVzc2FnZSBidWZmZXIgb25jZSBwZXIgcHJvY2VzczsgcHFf
YmVnaW5tZXNzYWdlX3JldXNlKCkKKwkJICogYW5kIHBxX2VuZG1lc3NhZ2VfcmV1c2UoKSByZXNl
dCBhbmQgcmV1c2UgaXQgb24gZWFjaCBjYWxsIHRvIGF2b2lkCisJCSAqIHBhbGxvYyBvdmVyaGVh
ZC4KKwkJICovCisJCWlmICghcHJvZ3Jlc3NfbWVzc2FnZV9pbml0aWFsaXplZCkKKwkJeworCQkJ
aW5pdFN0cmluZ0luZm8oJnByb2dyZXNzX21lc3NhZ2UpOworCQkJcHJvZ3Jlc3NfbWVzc2FnZV9p
bml0aWFsaXplZCA9IHRydWU7CisJCX0KKworCQlwcV9iZWdpbm1lc3NhZ2VfcmV1c2UoJnByb2dy
ZXNzX21lc3NhZ2UsIFBxTXNnX1Byb2dyZXNzKTsKIAkJcHFfc2VuZGludDMyKCZwcm9ncmVzc19t
ZXNzYWdlLCBpbmRleCk7CiAJCXBxX3NlbmRpbnQ2NCgmcHJvZ3Jlc3NfbWVzc2FnZSwgaW5jcik7
Ci0JCXBxX2VuZG1lc3NhZ2UoJnByb2dyZXNzX21lc3NhZ2UpOworCQlwcV9lbmRtZXNzYWdlX3Jl
dXNlKCZwcm9ncmVzc19tZXNzYWdlKTsKIAl9CiAJZWxzZQogCQlwZ3N0YXRfcHJvZ3Jlc3NfaW5j
cl9wYXJhbShpbmRleCwgaW5jcik7Ci0tIAoyLjUwLjEgKEFwcGxlIEdpdC0xNTUpCgo=
--000000000000ea501a06538536b3--