Horton
Menu

Re: Enhancing Memory Context Statistics Reporting

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Rahila Syed <rahilasyed90@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, torikoshia <torikoshia@oss.nttdata.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2026-01-14T13:26:24Z
Lists: pgsql-hackers 
On Tue, Jan 13, 2026 at 4:47 PM Andres Freund <andres@anarazel.de> wrote:
> I'm pretty sure that doesn't generally happen. There's promotion to FATAL if
> the top-level sigsetjmp() hasn't yet run (c.f. the check for
> PG_exception_stack in errstart()), but once it has been reached, it stays
> configured.

All right, then I guess I don't fully understand how the
error-outside-of-a-transaction case is handled. But I still think that
code like this needs to run in a transaction to avoid unexpected and
undesirable results. Do you see it differently?

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Cross-check lists of built-in LWLock tranches.

  2. Convert strncpy to strlcpy

  3. Typo and doc fixups for memory context reporting

  4. Add missing string terminator

  5. Rename argument in pg_get_process_memory_contexts().

  6. Add function to get memory context stats for processes