Re: pgsql: Add function to log the memory contexts of specified backend pro

Fujii Masao <masao.fujii@oss.nttdata.com>

From: Fujii Masao <masao.fujii@oss.nttdata.com>

To: Robert Haas <robertmhaas@gmail.com>

Cc: Fujii Masao <fujii@postgresql.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-05-01T17:27:54Z

Lists: pgsql-hackers

Commits

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

Add guard to prevent recursive memory context logging.
- 1a9a49699c21 14.21 landed
- 0fc2f533a96c 15.16 landed
- 3853f61681e8 16.12 landed
- 699293d2749a 17.8 landed
- b863d8d87fc1 18.2 landed
- b3ccb0a2cb2e 19 (unreleased) landed
Add function to log the memory contexts of specified backend process.
- 43620e328617 14.0 cited
Add pg_backend_memory_contexts system view.
- 3e98c0bafb28 14.0 cited


On 2025/05/01 21:42, Robert Haas wrote:
> On Thu, May 1, 2025 at 3:53 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>> Just idea, what do you think about adding a flag to indicate whether
>> ProcessLogMemoryContextInterrupt() is currently running? Then,
>> when a backend receives a signal and ProcessLogMemoryContextInterrupt()
>> is invoked, it can simply return immediately if the flag is already set
>> like this:
> 
> I think that something like this could work, but you would need more
> than this. Otherwise, if the function errors out, the flag would
> remain permanently set.

Yes, we need to either use PG_TRY()/PG_FINALLY() or handle the flag as
a global variable and reset it in the error handling path. I think using
PG_TRY()/PG_FINALLY() is the simpler option.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION