Re: Enhancing Memory Context Statistics Reporting

Rahila Syed <rahilasyed90@gmail.com>

From: Rahila Syed <rahilasyed90@gmail.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-01-08T12:03:01Z
Lists: pgsql-hackers

Attachments

Hi Fujii-san,

Thank you for testing the feature.


> Issue 1: Error with pg_get_process_memory_contexts()
> When I used pg_get_process_memory_contexts() on the PID of a backend
> process
> that had just caused an error but hadn’t rolled back yet,
> the following error occurred:
>
>    Session 1 (PID=70011):
>    =# begin;
>    =# select 1/0;
>    ERROR:  division by zero
>
>    Session 2:
>    =# select * from pg_get_process_memory_contexts(70011, false);
>
>    Session 1 terminated with:
>    ERROR:  ResourceOwnerEnlarge called after release started
>    FATAL:  terminating connection because protocol synchronization was lost
>
> In this scenario, a DSM segment descriptor is created and associated with
the
CurrentResourceOwner, which is set to the aborting transaction's resource
owner.
This occurs when ProcessGetMemoryContextInterrupts is called by the backend
while a transaction is still open and about to be rolled back.

I believe this issue needs to be addressed in the DSA and DSM code by
adding
a check to ensure that the CurrentResourceOwner is not about to be released
before
creating a DSM under the CurrentResourceOwner.

The attached fix resolves this issue. However, for a more comprehensive
solution,
I believe the same change should be extended to other parts of the DSA and
DSM
code where CurrentResourceOwner is referenced.

Issue 2: Segmentation Fault
> When I ran pg_get_process_memory_contexts() every 0.1 seconds using
> \watch command while running "make -j 4 installcheck-world",
> I encountered a segmentation fault:
>
>    LOG:  client backend (PID 97975) was terminated by signal 11:
> Segmentation fault: 11
>    DETAIL:  Failed process was running: select infinite_recurse();
>    LOG:  terminating any other active server processes
>
> I have not been able to reproduce this issue. Could you please clarify
which process you ran
pg_get_process_memory_context() on, with the interval of 0.1? Was it a
backend process
created by make installcheck-world, or some other process?

Thank you,
Rahila Syed

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