| From: | Gaurav Singh <gaurav(dot)singh(at)yugabyte(dot)com> |
|---|---|
| To: | daniel(at)yesql(dot)se |
| Cc: | Lukas Fittl <lukas(at)fittl(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Memory leak in pg_stat_statements when qtext file contains invalid encoding |
| Date: | 2026-03-27 08:57:37 |
| Message-ID: | CAEcQ1bZu21gi3aE6UzXTnLsajsv15PfSv=28wGk9Z48rnA-njw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> 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 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> > On 27 Mar 2026, at 09:21, Lukas Fittl <lukas(at)fittl(dot)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
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2026-03-27 08:59:32 | Re: Memory leak in pg_stat_statements when qtext file contains invalid encoding |
| Previous Message | Daniel Gustafsson | 2026-03-27 08:51:37 | Re: Memory leak in pg_stat_statements when qtext file contains invalid encoding |