public inbox for [email protected]  

help / color / mirror / Atom feed

From: Daniel Gustafsson <[email protected]>
To: Lukas Fittl <[email protected]>
Cc: Gaurav Singh <[email protected]>
Cc: [email protected]
Subject: Re: Memory leak in pg_stat_statements when qtext file contains invalid encoding
Date: Fri, 27 Mar 2026 09:51:37 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAP53Pky1575W1euSUwj2Zc5b0kBFZqpNuvMOGCvU_bR1tmD7zA@mail.gmail.com>
References: <CAEcQ1bYR9s4eQLFDjzzJHU8fj-MTbmRpW-9J-r2gsCn+HEsynw@mail.gmail.com>
	<CAP53Pky1575W1euSUwj2Zc5b0kBFZqpNuvMOGCvU_bR1tmD7zA@mail.gmail.com>

> On 27 Mar 2026, at 09:21, Lukas Fittl <[email protected]> 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

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Memory leak in pg_stat_statements when qtext file contains invalid encoding
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox