MIME-Version: 1.0
References: <CAEcQ1bYR9s4eQLFDjzzJHU8fj-MTbmRpW-9J-r2gsCn+HEsynw@mail.gmail.com>
 <CAP53Pky1575W1euSUwj2Zc5b0kBFZqpNuvMOGCvU_bR1tmD7zA@mail.gmail.com> <91A12197-68B4-4C9E-8F5B-DB26D9FA30C5@yesql.se>
In-Reply-To: <91A12197-68B4-4C9E-8F5B-DB26D9FA30C5@yesql.se>
From: Gaurav Singh <gaurav.singh@yugabyte.com>
Date: Fri, 27 Mar 2026 14:27:37 +0530
Message-ID: <CAEcQ1bZu21gi3aE6UzXTnLsajsv15PfSv=28wGk9Z48rnA-njw@mail.gmail.com>
Subject: Re: Memory leak in pg_stat_statements when qtext file contains
 invalid encoding
To: daniel@yesql.se
Cc: Lukas Fittl <lukas@fittl.com>, pgsql-bugs@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000056d6a064dfdb206"
Archived-At: <https://www.postgresql.org/message-id/CAEcQ1bZu21gi3aE6UzXTnLsajsv15PfSv%3D28wGk9Z48rnA-njw%40mail.gmail.com>
Precedence: bulk

--000000000000056d6a064dfdb206
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> We could also use palloc_extended() with MCXT_ALLOC_NO_OOM to avoid
erroring
> out on OOM and be able to return NULL?

Oh, it seems palloc_extended() would be a better fix.


--
Gaurav


On Fri, Mar 27, 2026 at 2:21=E2=80=AFPM Daniel Gustafsson <daniel@yesql.se>=
 wrote:

> > On 27 Mar 2026, at 09:21, Lukas Fittl <lukas@fittl.com> wrote:
>
> > But I think you're correct about qbuffer - because that buffer is
> > using malloc (not palloc), its not part of any memory context, and so
> > it will happily leak on abort.
> >
> > It appears our use of malloc in pg_stat_statements is so that we can
> > fail on OOM and return NULL without a jump. I think that makes sense
> > for when a GC cycle was triggered during regular query execution
> > (since we don't want to error the original query), but it seems like
> > just bubbling up the OOM if needed when querying the
> > pg_stat_statements function seems fine.
>
> We could also use palloc_extended() with MCXT_ALLOC_NO_OOM to avoid
> erroring
> out on OOM and be able to return NULL?
>
> --
> Daniel Gustafsson
>
>

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

<div dir=3D"ltr">&gt; We could also use palloc_extended() with MCXT_ALLOC_N=
O_OOM to avoid erroring<br>&gt; out on OOM and be able to return NULL?<br><=
br>Oh, it seems palloc_extended() would be a better fix.<br><br><br>--<div>=
Gaurav<br><br></div></div><br><div class=3D"gmail_quote gmail_quote_contain=
er"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 27, 2026 at 2:21=E2=
=80=AFPM Daniel Gustafsson &lt;<a href=3D"mailto:daniel@yesql.se">daniel@ye=
sql.se</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">&gt; On 27 Mar 2026, at 09:21, Lukas Fittl &lt;<a href=3D"mailto:luka=
s@fittl.com" target=3D"_blank">lukas@fittl.com</a>&gt; wrote:<br>
<br>
&gt; But I think you&#39;re correct about qbuffer - because that buffer is<=
br>
&gt; using malloc (not palloc), its not part of any memory context, and so<=
br>
&gt; it will happily leak on abort.<br>
&gt; <br>
&gt; It appears our use of malloc in pg_stat_statements is so that we can<b=
r>
&gt; fail on OOM and return NULL without a jump. I think that makes sense<b=
r>
&gt; for when a GC cycle was triggered during regular query execution<br>
&gt; (since we don&#39;t want to error the original query), but it seems li=
ke<br>
&gt; just bubbling up the OOM if needed when querying the<br>
&gt; pg_stat_statements function seems fine.<br>
<br>
We could also use palloc_extended() with MCXT_ALLOC_NO_OOM to avoid errorin=
g<br>
out on OOM and be able to return NULL?<br>
<br>
--<br>
Daniel Gustafsson<br>
<br>
</blockquote></div>

--000000000000056d6a064dfdb206--