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: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-05-02T00:02:43Z

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

Attachments

v1-0001-Add-guard-to-prevent-recursive-memory-contexts-lo.patch (text/plain) patch v1-0001


On 2025/05/02 2:27, Fujii Masao wrote:
> 
> 
> 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.

I've implemented the patch in that way. Patch attached.

Regards,

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